# PHP session upload progress vulnerability after the PHP2Shell patch > Source: > Published: 2026-10-23 15:06:24+00:00 *Originally published at [hamzaahmadaslam.com](https://hamzaahmadaslam.com/blog/php-session-upload-progress-vulnerability).* How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing. The PHP session upload progress vulnerability remains open after the PHP2Shell patch. On 23 October 2026, php.net warned about an unlikely remote code execution path tracked as CVE-2026-115560; the 21 October security releases still fix the two original PHP2Shell vulnerabilities. Set `session.upload_progress.enabled=0` in server-level PHP configuration and restart your PHP workers until the next regular bugfix release. The PHP project published an [informational advisory on 23 October](https://www.php.net/archive/2026.php#2026-10-23-1), two days after releasing fixes for CVE-2026-109618 and CVE-2026-109619. The new advisory describes an unlikely route to remote code execution (RCE), where an attacker can cause a server to run code. | Date | Event | Source | |---|---|---| | 21 Oct 2026 | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released with fixes for the two original PHP2Shell vulnerabilities. | php.net | | 21 Oct 2026 | Issue #24481 opened, reporting a separate `unserialize()` use-after-free problem. | php-src GitHub | | 22 to 23 Oct 2026 | Hosted Power released updates to its `php_uploadprogress_guard` extension, including version 3.2.4 on 23 October. | Hosted Power GitHub | | 23 Oct 2026 | PHP published the session upload progress advisory and assigned CVE-2026-115560 to the remaining vector. | php.net | The earlier [CVE-2026-109619 advisory](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) recommended disabling session upload progress. That blocked its confirmed session-related attack paths, but not every variant of CVE-2026-109619. It offered no protection against CVE-2026-109618. PHP says updating is the only complete response to the original vulnerabilities. Disabling upload progress adds protection against the remaining session-related risk. A session lets PHP retain temporary information between requests from the same visitor. PHP can track file upload progress through session data. According to the [PHP session upload progress manual](https://www.php.net/manual/en/session.upload-progress.php), tracking starts when a multipart upload includes a form field named by `session.upload_progress.name`. The default field name is `PHP_SESSION_UPLOAD_PROGRESS`. Another request can read the stored information to update an upload progress indicator. The feature has existed since PHP 5.4.0 and is enabled by default. Upload progress operates during request parsing, before the application's ordinary PHP code runs. That early processing is why it appeared in the original PHP2Shell advisory. The confirmed CVE-2026-109619 session path involved internal state surviving between requests. The new advisory concerns a narrower combination of session settings. Upload progress bars can use other methods, including JavaScript. Test your site's uploads after disabling this PHP feature instead of assuming every progress indicator depends on it. PHP calls the CVE-2026-115560 scenario unlikely because all three conditions must occur: `session.serialize_handler` as either `php_binary` or `php_serialize`.` session_start()`, application code changes that handler to `php` using `ini_set()`.` session.upload_progress.enabled` remains enabled. The serialize handler controls how PHP converts session information into a stored format and reads it back. The names `php`, `php_binary` and `php_serialize` refer to different storage formats. An application that uses `php_serialize` consistently does not match the described condition. Neither does one that uses the default `php` handler without changing it at runtime. PHP explicitly says applications that never change their serialize handler at runtime can keep upload progress enabled. Ask your hosting provider or developer to confirm: A hosting dashboard showing `session.serialize_handler=php` provides only part of the answer. Application code may change that setting. If nobody has checked the code, disabling upload progress is the simpler precaution. Search the site's PHP files for references to the serialize handler. From a WordPress installation directory, run: ``` grep -RIn --include='*.php' 'session.serialize_handler' wp-content/ ``` Inspect matches in plugins, themes, must-use plugins and custom code. Search application and vendor directories outside `wp-content` when relevant. Look for an `ini_set()` call changing `session.serialize_handler` to `php` before `session_start()`. Check the original handler value in `php.ini` and PHP-FPM pool settings. A search with no matches cannot establish safety when configuration changes occur elsewhere or use dynamically constructed code. As of 23 October 2026, php.net has published neither a separate affected-version list nor a fix date for CVE-2026-115560. The narrow CVE-2026-115560 condition should not distract from servers still missing the original PHP2Shell fixes. PHP 8.1 and older receive no new releases from the PHP project. For the October emergency, PHP provided minimal source backports for PHP 7.4, 8.0 and 8.1 on branches named `PHP--CVE-2026-109618-109619`. These help vendors build patched versions. They do not restore regular security support. [VirusTotal's 21 October exposure analysis](https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html) shows how widespread older installations remain. | VirusTotal measurement | Approximate IP addresses | |---|---| | Fingerprinted as running PHP | 5.1 million | | Disclosing a PHP version | 1.1 million | | On supported branches 8.2 to 8.5 | 272,000 | | On end-of-life branches 5.4 to 8.1 | 758,000 | | Running PHP 7.4 | 187,000 | | Running PHP 5.4 | 119,000 | | Running the September releases immediately preceding the fixes | 85,000 | VirusTotal calculated these figures from Internet scans on 21 October, using rounded medians of seven runs. These are exposure figures, not counts of confirmed vulnerable or compromised websites. A disclosed version cannot reliably show whether a distribution has applied a backported fix. VirusTotal also warned that `expose_php=Off` only hides the version header. It does not remove a vulnerability. An operating system package may retain an older version number while incorporating security fixes. Check the vendor's security notices and package changelog. Confirm that the installed build fixes both CVE-2026-109618 and CVE-2026-109619. Disabling upload progress cannot compensate for missing fixes to other attack paths. A package update does not establish which PHP code existing processes are running. PHP workers handle incoming requests. Existing workers may retain previously loaded code until they exit. Restart the appropriate service after updating PHP. The [guide to WordPress PHP workers](https://hamzaahmadaslam.com/blog/wordpress-php-workers) explains how these processes handle WordPress requests. Sansec updated its PHP2Shell research on 22 October. The company said mass exploitation was less likely than initially assessed because attacks required specific conditions and target knowledge. Sansec still advised updating PHP. Set `session.upload_progress.enabled` to `0` in configuration applied before PHP parses incoming requests. The 21 October advisory names `php.ini`, an FPM pool or server configuration as suitable locations. Application-level changes happen too late. Identify how your website runs PHP. PHP-FPM, the FastCGI Process Manager, handles PHP requests through managed worker processes. A pool is a group of workers with its own configuration. Apache `mod_php` runs PHP directly inside Apache processes. Managed hosting providers may control these settings. Check the web server's PHP version and configuration files, since command-line PHP can use different settings. Find the `php.ini` file used by the website's PHP service. Add or change: ``` session.upload_progress.enabled = 0 ``` Check for another configuration setting that overrides it. Inspect each relevant PHP version or pool if the server hosts multiple sites. This disables session upload progress tracking, not ordinary PHP file uploads. An administrator can enforce the setting in the relevant PHP-FPM pool: ``` php_admin_flag[session.upload_progress.enabled] = off ``` The `php_admin_flag` directive sets a Boolean PHP option administratively. PHP's FPM documentation confirms that values applied this way cannot be overridden using `ini_set()`. Check that you are editing the pool serving your website. If Apache loads PHP as a module, use this directive in the appropriate server or virtual-host configuration: ``` php_admin_flag session.upload_progress.enabled off ``` The PHP manual states that `php_admin_flag` is unavailable in `.htaccess`. Do not put this directive into `.htaccess` on a PHP-FPM server. It applies to Apache `mod_php`. Hosting control panels often expose PHP options through a PHP INI editor or PHP configuration screen. Set `session.upload_progress.enabled` to Off or `0`, then confirm where the panel writes it. A panel may save the change only in `.user.ini`. PHP's advisory warns against relying on FPM `.user.ini` because it is processed too late for this protection. If you cannot inspect the server configuration, send your provider this instruction: Set `session.upload_progress.enabled=0` in the PHP startup configuration or relevant PHP-FPM pool, restart every affected PHP worker, and confirm the running value for my website. Please do not rely only on `.user.ini` or application-level `ini_set()`. Restart the service running PHP after saving the configuration. For example, on Debian or Ubuntu using the `php8.4-fpm` systemd service: ``` sudo systemctl restart php8.4-fpm ``` Use the service name matching your installation. For Apache running PHP through `mod_php`, a Debian or Ubuntu example is: ``` sudo systemctl restart apache2 ``` Other systems use different names. Managed hosts may provide a restart control or require support assistance. Confirm every affected worker has restarted. Apply the change across all servers handling your website's PHP requests. Check both the startup configuration and the value reported by the running web PHP process. An administrator can temporarily create a restricted diagnostics page: ```