How to Disable PHP Session Upload Progress Safely

To disable PHP session upload progress, set session.upload_progress.enabled=0 in configuration that PHP applies at startup (php.ini, an FPM pool or the server configuration), make it non-overridable, then restart every PHP worker. The PHP project recommends this for all servers that do not use the feature, after the October 2026 PHP2Shell vulnerabilities showed it could be used to reach remote code execution.

What is session upload progress in PHP?

Session upload progress is a PHP feature that records how much of a file upload has arrived in the user's session, so a page can show a progress bar. It has existed since PHP 5.4.0 and is enabled by default.

Few modern applications use it. Most upload progress bars are built in JavaScript in the browser, so for many servers the feature is on but nothing depends on it.

Why should you disable PHP session upload progress?

PHP's advisory for CVE-2026-109619 lists session upload progress as one of the validated paths to code execution, including on a normal PHP-FPM pool. A second, lower-risk issue published on October 23, 2026 (CVE-2026-115560) also involves the feature, and PHP again recommends turning it off until the next regular release.

The advisory goes further: if you do not need the feature, keep it disabled even after you patch. Disabling it removes attack surface without breaking anything for most sites.

Disabling it is not a fix on its own. The advisories say updating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is the only complete mitigation. Treat this setting as a layer on top of the update.

Check whether anything uses it

Before you change the setting, confirm nothing depends on it.

1. Search your application code and plugins for the session upload progress name and prefix settings and for the session key the feature writes. If nothing references them, nothing reads the data.
2. Ask the application owner or vendor whether their upload screens rely on server-side progress. Large file managers and some older CMS plugins are the usual cases.
3. Test an upload in staging with the feature off. Uploads still work; only the server-side progress data goes away.

Where to set the directive

The PHP advisory says to set it "administratively", meaning in a place applications cannot override. In practice:

• php.ini: add the directive to the main php.ini (or a file in the conf.d directory it loads) for every PHP version and SAPI on the host. Distributions usually keep separate php.ini files for the CLI, Apache and FPM, so changing one does not change the others.
• PHP-FPM pools: set it with php_admin_flag or php_admin_value in each pool file. Admin values cannot be changed by ini_set() or .user.ini.
• Apache mod_php: set it with php_admin_flag in the server or virtual host configuration, not with php_flag in .htaccess, which a site owner can change.
• Containers: bake the setting into the image's PHP configuration and rebuild. Changing a running container is lost on the next deploy.

The directive itself is one line:

session.upload_progress.enabled=0

Restart every worker

PHP reads startup settings when a worker process starts, so the change does nothing until the workers restart. The advisory is explicit: restart every worker.

• For PHP-FPM, restart (not only reload) each FPM service, one per PHP version if you run several.
• For mod_php, restart Apache.
• For managed hosting or a control panel, use the provider's option to restart PHP, or open a ticket.
• For containers, redeploy so every replica runs the new image.

How do you confirm the setting took effect?

Check the value reported by the running web SAPI, not by the command line, because the CLI often reads a different php.ini. An administrator-only phpinfo page or your monitoring agent's PHP check shows the effective value per site.

Repeat the check for each pool and each virtual host. A common miss is a second PHP version on the same server, left running for one legacy site, that still has the default.

Make it stick

Put the setting into your configuration management or image build, not only on the live server, so a rebuild does not quietly restore the default. Add a periodic check that alerts if any PHP endpoint reports it enabled.

This setting sits alongside the SAPI choice covered in mod_php vs PHP-FPM and why the SAPI changes your risk. Servers stuck on old branches that may never get a full fix are covered in why end-of-life PHP versions need a retirement plan. If you find signs of compromise while you are in the logs, preserve them first using how to preserve evidence before patching a server.