{"slug": "php-session-upload-progress-vulnerability-after-the-php2shell-patch", "title": "PHP session upload progress vulnerability after the PHP2Shell patch", "summary": "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.", "body_md": "*Originally published at [hamzaahmadaslam.com](https://hamzaahmadaslam.com/blog/php-session-upload-progress-vulnerability).*\n\nHow this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.\n\nThe 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.\n\nThe 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.\n\nThe new advisory describes an unlikely route to remote code execution (RCE), where an attacker can cause a server to run code.\n\n| Date | Event | Source | \n|---|---|---|\n| 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 | \n| 21 Oct 2026 | Issue #24481 opened, reporting a separate `unserialize()` use-after-free problem. | php-src GitHub | \n| 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 | \n| 23 Oct 2026 | PHP published the session upload progress advisory and assigned CVE-2026-115560 to the remaining vector. | php.net | \n\nThe 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.\n\nPHP says updating is the only complete response to the original vulnerabilities. Disabling upload progress adds protection against the remaining session-related risk.\n\nA session lets PHP retain temporary information between requests from the same visitor.\n\nPHP 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`.\n\nThe default field name is `PHP_SESSION_UPLOAD_PROGRESS`. Another request can read the stored information to update an upload progress indicator.\n\nThe feature has existed since PHP 5.4.0 and is enabled by default.\n\nUpload 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.\n\nThe new advisory concerns a narrower combination of session settings.\n\nUpload 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.\n\nPHP calls the CVE-2026-115560 scenario unlikely because all three conditions must occur:\n\n`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.\nThe serialize handler controls how PHP converts session information into a stored format and reads it back.\n\nThe names `php`, `php_binary` and `php_serialize` refer to different storage formats.\n\nAn 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.\n\nPHP explicitly says applications that never change their serialize handler at runtime can keep upload progress enabled.\n\nAsk your hosting provider or developer to confirm:\n\nA hosting dashboard showing `session.serialize_handler=php` provides only part of the answer. Application code may change that setting.\n\nIf nobody has checked the code, disabling upload progress is the simpler precaution.\n\nSearch the site's PHP files for references to the serialize handler.\n\nFrom a WordPress installation directory, run:\n\n```\ngrep -RIn --include='*.php' 'session.serialize_handler' wp-content/\n```\n\nInspect matches in plugins, themes, must-use plugins and custom code. Search application and vendor directories outside `wp-content` when relevant.\n\nLook for an `ini_set()` call changing `session.serialize_handler` to `php` before `session_start()`.\n\nCheck 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.\n\nAs of 23 October 2026, php.net has published neither a separate affected-version list nor a fix date for CVE-2026-115560.\n\nThe narrow CVE-2026-115560 condition should not distract from servers still missing the original PHP2Shell fixes.\n\nPHP 8.1 and older receive no new releases from the PHP project.\n\nFor 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`.\n\nThese help vendors build patched versions. They do not restore regular security support.\n\n[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.\n\n| VirusTotal measurement | Approximate IP addresses | \n|---|---|\n| Fingerprinted as running PHP | 5.1 million | \n| Disclosing a PHP version | 1.1 million | \n| On supported branches 8.2 to 8.5 | 272,000 | \n| On end-of-life branches 5.4 to 8.1 | 758,000 | \n| Running PHP 7.4 | 187,000 | \n| Running PHP 5.4 | 119,000 | \n| Running the September releases immediately preceding the fixes | 85,000 | \n\nVirusTotal calculated these figures from Internet scans on 21 October, using rounded medians of seven runs.\n\nThese 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.\n\nVirusTotal also warned that `expose_php=Off` only hides the version header. It does not remove a vulnerability.\n\nAn operating system package may retain an older version number while incorporating security fixes.\n\nCheck the vendor's security notices and package changelog. Confirm that the installed build fixes both CVE-2026-109618 and CVE-2026-109619.\n\nDisabling upload progress cannot compensate for missing fixes to other attack paths.\n\nA package update does not establish which PHP code existing processes are running.\n\nPHP workers handle incoming requests. Existing workers may retain previously loaded code until they exit.\n\nRestart 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.\n\nSansec 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.\n\nSet `session.upload_progress.enabled` to `0` in configuration applied before PHP parses incoming requests.\n\nThe 21 October advisory names `php.ini`, an FPM pool or server configuration as suitable locations. Application-level changes happen too late.\n\nIdentify how your website runs PHP.\n\nPHP-FPM, the FastCGI Process Manager, handles PHP requests through managed worker processes. A pool is a group of workers with its own configuration.\n\nApache `mod_php` runs PHP directly inside Apache processes.\n\nManaged hosting providers may control these settings. Check the web server's PHP version and configuration files, since command-line PHP can use different settings.\n\nFind the `php.ini` file used by the website's PHP service.\n\nAdd or change:\n\n```\nsession.upload_progress.enabled = 0\n```\n\nCheck for another configuration setting that overrides it. Inspect each relevant PHP version or pool if the server hosts multiple sites.\n\nThis disables session upload progress tracking, not ordinary PHP file uploads.\n\nAn administrator can enforce the setting in the relevant PHP-FPM pool:\n\n```\nphp_admin_flag[session.upload_progress.enabled] = off\n```\n\nThe `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()`.\n\nCheck that you are editing the pool serving your website.\n\nIf Apache loads PHP as a module, use this directive in the appropriate server or virtual-host configuration:\n\n```\nphp_admin_flag session.upload_progress.enabled off\n```\n\nThe PHP manual states that `php_admin_flag` is unavailable in `.htaccess`.\n\nDo not put this directive into `.htaccess` on a PHP-FPM server. It applies to Apache `mod_php`.\n\nHosting control panels often expose PHP options through a PHP INI editor or PHP configuration screen.\n\nSet `session.upload_progress.enabled` to Off or `0`, then confirm where the panel writes it.\n\nA 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.\n\nIf you cannot inspect the server configuration, send your provider this instruction:\n\nSet `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()`.\n\nRestart the service running PHP after saving the configuration.\n\nFor example, on Debian or Ubuntu using the `php8.4-fpm` systemd service:\n\n```\nsudo systemctl restart php8.4-fpm\n```\n\nUse the service name matching your installation.\n\nFor Apache running PHP through `mod_php`, a Debian or Ubuntu example is:\n\n```\nsudo systemctl restart apache2\n```\n\nOther systems use different names. Managed hosts may provide a restart control or require support assistance.\n\nConfirm every affected worker has restarted. Apply the change across all servers handling your website's PHP requests.\n\nCheck both the startup configuration and the value reported by the running web PHP process.\n\nAn administrator can temporarily create a restricted diagnostics page:\n\n```\n