session.upload_progress.enabled=0 blocks the confirmed session paths of CVE-2026-109619 and is PHP's stated mitigation for CVE-2026-115560. It does nothing for CVE-2026-109618.⁠1 Install the fixed PHP build first, set this at server level, restart every PHP worker, and treat the setting as a mitigation, not a fix.⁠1

You need this if: you run PHP and can't yet apply the 21 October fixes, or you've patched and want protection against CVE-2026-115560 until its fix ships. If your application relies on PHP session upload progress, do not disable it blindly. Identify the dependency, assess the applicable CVEs and PHP advisory conditions, and prioritize a fixed PHP build or an alternative upload-progress implementation. Do not assume leaving the feature enabled is safe. Status as of 3 November 2026: PHP has announced no fix for CVE-2026-115560.⁠1

The complete PHP2Shell guide covers all three flaws. This article covers one setting.

What the setting does, and what it covers

Session upload progress is a PHP feature that records the progress of a file upload in the session. session.upload_progress.enabled controls it. The PHP manual lists the default as "1" (on) and the changeable scope as INI_PERDIR.⁠2

Three flaws, three different answers:

CVEDoes this setting help?
CVE-2026-109619 (stale global state)Partly. PHP says it blocks the confirmed session paths, not other variants.⁠1
CVE-2026-115560 (the separate third flaw)Yes. PHP names it as the mitigation until the next regular release.⁠1
CVE-2026-109618 (out-of-memory corruption)No. PHP's controls for it are a memory-limit change, a low post_max_size and request-size limits.⁠1

The 21 October advisory lists the setting for CVE-2026-109619. PHP's 23 October note says to keep it in place if you applied it then, and to set it if you didn't, until the next regular bugfix release.⁠1 The third PHP flaw this setting also covers needs an unusual mix of configuration and application code. PHP says applications that never switch the serialize handler at runtime can leave the feature on.⁠1

The setting does not replace the update. PHP says updating is the only complete solution for the first two flaws.⁠1

What turning it off breaks

PHP's session upload-progress feature stops working. A site that draws an upload progress bar from it loses the bar. Search your code, plugins and vendor directory for session.upload_progress and PHP_SESSION_UPLOAD_PROGRESS, the default name of the form field PHP watches.⁠2

No matches reduce the likelihood of a dependency, but do not prove the feature is unused. Dependencies can be indirect, set through configuration, or sit in deployed code outside the directories you searched. Test upload workflows in staging before changing production settings.

If something does depend on it, the answer is a fixed PHP build or an alternative upload-progress implementation, not leaving the feature on and hoping.

Where to set it, and where not to

Set it at server level: php.ini, the PHP-FPM pool or the server configuration, so it applies before request parsing. PHP's advisory says to restart every worker and gives one warning: "Do not rely on ini_set() or FPM .user.ini."⁠1 A changed file does nothing for workers that are already running.

Steps by environment

The right file and the right service name depend on how PHP runs on your server. First find out which of these you have: Apache running PHP as mod_php, Apache or nginx forwarding PHP requests to PHP-FPM, or shared hosting where you can't touch server-level configuration. Sources are PHP's advisory and manual, and each vendor's own documentation. Syntax is for current PHP 8 releases. Config file locations and service names vary by distribution and host.

Apache with mod_php

PHP's manual describes php_admin_flag name on|off as an Apache configuration directive for PHP running as an Apache module. It can't go in .htaccess and can't be overridden by .htaccess or ini_set().⁠3 Don't use php_value for a boolean.⁠3

php_admin_flag session.upload_progress.enabled off

This applies to mod_php only. If Apache forwards PHP to PHP-FPM, use the FPM steps below. Restart Apache so every worker loads the change.

PHP-FPM, behind Apache or nginx

Use the file that matches the context. In the php.ini that FPM reads, use the plain INI form:

session.upload_progress.enabled = 0

In an FPM pool file, use the manual's pool syntax. Settings made this way can't be overridden with ini_set().⁠4

php_admin_flag[session.upload_progress.enabled] = off

php_admin_flag[...] belongs in a pool file, not in php.ini. Then restart the PHP-FPM service. The unit name and file paths differ by distribution, so check yours.

cPanel

Server admins: WHM's MultiPHP INI Editor, Editor Mode, edits the php.ini for the PHP version you select.⁠6 cPanel's support article points system-wide changes to WHM, not the account-level editor.⁠8 The account-level editor targets a home directory or a domain's document root.⁠7 That is per-account scope, so account holders on shared hosting should ask the host. The cPanel pages I opened don't say whether Save restarts workers. Restart PHP-FPM and Apache, and confirm with the check below.

Plesk

Plesk's knowledge base sends domain-level changes to Domains > your domain > PHP Settings, and server-wide php.ini changes to Tools & Settings > PHP Settings > your PHP version > the php.ini tab. The "Additional configuration directives" field is for Plesk administrators only.⁠9 The article doesn't say that saving restarts workers. Confirm the value afterwards.

Docker and containers

Put the setting in an .ini file in the image's PHP config directory, rebuild the image and redeploy. Server Side Up's docs show the pattern: copy a file into /usr/local/etc/php/conf.d/.⁠10 Restarting a container built from the unchanged image changes nothing.

Shared hosting without server access

If you can't change server-level configuration, ask the host to apply the setting, in writing. Account-level editors and .user.ini are not equivalent, and PHP advises against relying on the latter. Reported webhosting.today's roundup records that InMotion, Hostinger and Infomaniak switched upload progress off on their platforms. It also notes that one.com warned its countermeasures could disrupt uploads and direct database access, and that GoDaddy asked VPS customers to apply the setting themselves.⁠11

How you'd notice

The setting is missing or not applied if the web-serving PHP still reports upload progress on. The usual causes: you edited the wrong php.ini, you set it only for the command-line PHP, or you didn't restart the workers.

A command-line check does not show what the website uses. The command-line PHP can read different settings from the web-serving PHP.

PHP-FPM's man page describes two options that inspect the FPM binary's configuration and information: -tt dumps the configuration before exit, and -i prints PHP information and configuration.⁠5

php-fpm -tt
php-fpm -i

The executable name differs by distribution, for example php-fpm8.3 on Debian-family systems, and the output varies by version and environment. These commands inspect FPM configuration. Neither proves the setting an active web request is using.

Check the effective value through the web-serving PHP instead. Prefer an authenticated or locally restricted check. If you use a temporary phpinfo() page, restrict access to your own address or a login, read session.upload_progress.enabled, delete the file straight after, and confirm the page no longer loads. A public phpinfo() page hands server details to anyone who finds it.

It broke something if an upload progress bar stops updating or an upload page behaves differently after the change.

Do this

Do today

  1. Check whether a fixed PHP build is available for your branch or vendor: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a verified vendor backport.
  2. Install the fixed build, then restart or replace the PHP workers in the same operation. The steps to apply the actual patch cover servers you run. The 21 October releases fix CVE-2026-109618 and CVE-2026-109619 only.⁠1
  3. Search your code, plugins and vendor/ for session.upload_progress and PHP_SESSION_UPLOAD_PROGRESS, then test your upload workflows in staging with the setting off.
  4. Apply session.upload_progress.enabled=0 at server level for CVE-2026-115560 if staging shows nothing depends on it, then restart every PHP worker.
  5. Verify the effective value through the web-serving PHP, not the command line.

Do this week

  • Plan an alternative upload-progress implementation for anything that depends on the feature, and prioritize it with the fixed build.
  • Confirm which PHP is serving your site before you trust any version number.
  • Ask your host to confirm in writing that the fixed build and the setting are in place, if you can't change the configuration yourself.
  • On PHP 8.1 or older, review other workarounds for older PHP for post_max_size and the rest.

Can wait

  • Re-check PHP's advisory for the CVE-2026-115560 fix.
  • Remove the setting only if you need the feature and the fix has shipped.