"The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much." — Gina Peter Banyard, PHP core developer and documentation writer funded by the PHP Foundation.
What PHP is about to ship at 14:00 UTC on October 21
PHP has scheduled a release for 14:00 UTC on October 21 that will fix two critical remote code execution flaws collectively discussed as "PHP2Shell." PHP rates the flaws 9.2 out of 10 and has not published the fixed versions, which branches are affected, or any in-release mitigations ahead of that fix. The project says full details and the fixed versions will be announced with the release.
Why the circulating workaround is not a full defense
The one-line configuration change being passed around — session.upload_progress.enabled=0 — disables PHP's Session Upload Progress feature. GMO Flatt Security of Tokyo initially suggested the change on October 21 as a possible mitigation but later updated that guidance (timestamped 14:00 Japan time / 05:00 UTC) to say the setting alone is not a complete fix and that "attacks getting around it are expected." An anonymous independent code audit included in the public discussion also argues that the specific bug others describe in that feature does not exist in released PHP; GMO Flatt and PHP have not confirmed the flaw lives in Session Upload Progress.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleOperational realities: what actually reduces your risk now
Until the patch lands, the source recommends measures that lower exposure rather than promise safety. Those measures include removing exposed PHP services from the internet or placing them behind access controls, restricting what a compromised server can reach, and preparing to apply the update immediately when it is released. CERT-EU advises isolating internet-facing applications from public networks until a fix can be applied; a PHP core developer echoed that shutting a server down for a day "might be the most sensible thing to do," while acknowledging that is not reasonable for most organizations.
Practical checklist for administrators before and at patch time
- Confirm your update plan now: rehearse update steps, checks, configuration changes, and any approvals or emergency restarts you may need, as advised by GMO Flatt.
- When the fix is published, update the PHP runtime that serves web traffic — PHP-FPM, mod_php, or CGI — not the application layer.
- Verify configuration changes affect the web-serving process. The session.upload_progress.enabled setting is INI_PERDIR, so it can be set in php.ini, .htaccess, or .user.ini; .user.ini is read-only for CGI/FastCGI and is re-read only every 300 seconds by default.
- Confirm values on the runtime (PHP-FPM or mod_php) rather than relying on php -i at the shell.
- If you cannot patch immediately, restrict access with VPNs, allowlists, or authenticated edge access and make sure there is no direct path to the origin. Reduce data stored on the server, remove stored credentials (including cloud roles), reduce process privileges, and enable secure logging for later investigation.
How managed hosting, application operators, and security vendors fit in
Application updates (WordPress, Laravel, etc.) do not update the PHP runtime; the runtime is supplied by server packages, hosts, or container images. For customers on managed or shared hosting, the source advises asking the provider when a fixed PHP build will be available and to have the provider stand by. Hosting vendors build their packages only after PHP ships the fix; CloudLinux explicitly said its updated packages depend on the upstream release. Security vendors are split: watchTowr, which reproduced one of the flaws, says there is "no confirmed patch or workaround at this time," while Upwind continues to list the upload-progress setting as an immediate mitigation by relaying another researcher's analysis. Cloudflare added emergency "anomalous execution" rules on October 21, but those rules do not name PHP or these flaws and cover only traffic that passes through that provider; such rules can miss variants and are a weak stopgap, not a fix.
No exploitation had been reported as of October 21. watchTowr's FAQ listed none, the flaws were absent from CISA's catalog of known exploited flaws when last checked, and a short demonstration video that had circulated was removed; an audit stated the circulating proof-of-concept code does not fire. Treat those observations as a snapshot: the project expects definitive answers when the PHP release and advisory are published.
When the fix appears, check which branch versions are fixed, which versions PHP lists as affected, whether PHP confirms or rejects any configuration as mitigation, and whether session-related code changed — which will clarify whether the vulnerability lived in Session Upload Progress. After updating, review logs for any pre-patch activity.
