PHP session upload progress vulnerability after the PHP2Shell patch

PHP published an informational advisory on 23 October 2026 warning of a remaining remote code execution vector in its session upload progress feature, tracked as CVE-2026-115560, two days after the 21 October releases (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35) fixed the two original PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The project says the new scenario is unlikely because it requires session.serialize_handler set to php_binary or php_serialize, application code switching the handler to php via ini_set(), and session.upload_progress.enabled left on. The recommended mitigation is setting session.upload_progress.enabled=0 at the server level and restarting PHP workers until the next regular bugfix release.

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-<version -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: <?php phpinfo ; Open it through the website's normal web server. Find session.upload progress.enabled . Its running Local Value should be 0 or Off. Also inspect the PHP version, Server API and loaded configuration file. A Local Value of 0 alone is insufficient if it came only from .user.ini . Confirm the startup configuration enforces it. A phpinfo page exposes server details. Restrict access and delete the file immediately after checking. Do not rely on php -i or php --ini alone. Those commands inspect command-line PHP, which may use different configuration files. The change removes PHP's session-based upload progress tracking. Applications reading progress from PHP session data may lose their progress indicators. Ordinary PHP file uploads remain available. Test these workflows after making the change: Also test custom upload and import workflows outside standard WordPress interfaces. If something fails, check whether that feature reads PHP session upload progress information. Hosted Power's php uploadprogress guard https://github.com/HOSTED-POWER/php uploadprogress guard is an MIT-licensed PHP extension developed for the company's hosting fleet. The project released updates on 22 and 23 October, reaching version 3.2.4 on 23 October. Hosted Power says its extension detaches the upload progress handler at the parser level, including on patched PHP. It also claims protection for other PHP issues, including the separately reported unserialize problem. The vendor argues that normal applications do not need PHP's session upload progress feature enabled. PHP's official position is narrower: applications that never switch serialize handlers at runtime can keep upload progress enabled, although PHP recommends disabling it until the next release. The extension adds another component to maintain and test. It is a vendor-provided temporary protection, not a replacement for PHP security updates. A php-src issue opened on 21 October, 24481 https://github.com/php/php-src/issues/24481 , reports a use-after-free condition during unserialize . The unserialize function rebuilds PHP values from serialized data. A use-after-free occurs when software accesses memory after that memory has been released. The report describes a problem during internal cleanup when serialization-related operations occur again. A commenter reports reproducing the memory error under Valgrind on PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 and 7.4.33. Valgrind is a tool for detecting incorrect memory access. As of 23 October 2026, issue 24481 remains open with the label Status: Needs Triage . The page contains no PHP maintainer confirmation. Hosted Power also says its tests reproduced the problem and that its extension contains a workaround. That is separate vendor testing. The issue does not establish a connection to CVE-2026-115560, session upload progress or the confirmed PHP2Shell attack paths. Avoid calling unserialize on attacker-controlled data. Review existing uses where the data source is unclear, and watch for maintainer triage and any resulting PHP fix. Copy this block into a hosting support ticket or deployment checklist. Look: Active php.ini, PHP-FPM pool or Apache mod php server configuration. Set: session.upload progress.enabled = 0 before request parsing. Restart: The affected PHP-FPM service or Apache mod php service; restart all workers. Verify: Check the running web PHP value and confirm the server-level configuration. Test: WordPress Media Library, WooCommerce product images and form file uploads. Ask the host to confirm the PHP version and both original PHP2Shell fixes. If the setting was already disabled correctly after 21 October and workers restarted, PHP says to keep it in place. No additional action is required for this advisory. Three items need follow-up after 23 October. First, PHP says the next regular bugfix release will include the complete CVE-2026-115560 advisory. Its 23 October notice gives no release date. Second, check the full advisory when available. The informational notice describes the unusual configuration condition but gives no separate affected-version list. Third, plan your move away from PHP 8.2. PHP 8.2 reaches end of life on 31 December 2026. End of life means the PHP project stops providing security fixes for that branch. If your website still uses PHP 8.2, test an upgrade to a branch supported beyond that date. Keep upload progress disabled until the next release and review PHP's updated guidance. Confirm the installed PHP security update, upload progress setting and worker restart status. For the original vulnerabilities, use the PHP2Shell security update guide and full response checklist https://hamzaahmadaslam.com/blog/php-critical-security-update-php2shell . It covers fixed versions and the wider response to the 21 October releases. If your site shows unauthorized file changes, unexpected PHP scripts or other suspicious behavior, investigate the installation. The WordPress malware removal service https://hamzaahmadaslam.com/services/wordpress-malware-removal covers sites needing compromise investigation and cleanup. For an already patched, normally operating site, confirm the server-level setting, restart PHP if needed, and test the uploads your business uses.