You cannot fully block the two critical PHP flaws called PHP2Shell before today's fix, and the one setting being passed around as a workaround is not enough on its own, the security firm that suggested it now says.
PHP will release the fix at 14:00 UTC on October 21 for two flaws it rates 9.2 out of 10, and has given no workaround of its own. Until you can install it, what lowers your risk is taking exposed PHP off the internet or behind access controls, cutting what a compromised server can reach, and having the update ready to apply the moment it lands.
No attacks have been reported. PHP has not said which versions are affected, which part of PHP is involved, or whether any setting changes the risk; it says the full details and the fixed versions come with the release.
At the time of writing, that release was not yet out. So nobody outside the group that found the flaws can test whether a given defense works, which is why the advice below is about lowering risk, not promising safety.
The setting you were told to change is not protection
The workaround spreading on social media and security blogs is one line in a PHP configuration file: session.upload_progress.enabled=0. It turns off Session Upload Progress, a PHP feature that's enabled by default, which records how far a file upload has progressed so another request can check on it.
GMO Flatt Security, a Tokyo security firm, suggested setting it early on October 21, saying it could not be sure the change fully addresses the flaws but thought it would help with some probability.
Later the same day, the firm walked that back. In an update timestamped 14:00 Japan time (05:00 UTC), it said the setting alone is not a complete fix and that attacks getting around it are expected. It told administrators to prepare their update, watch for attack traffic before the release, and apply the fix as soon as it is out.
A PHP core developer said the same thing more bluntly. Replying to someone who suggested the upload-progress setting might patch the flaw, Gina Peter Banyard, a PHP core developer and documentation writer funded by the PHP Foundation, wrote: "The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much."
The setting cannot be relied on for two reasons. GMO Flatt expects a way around it but has not said what that is. And the whole idea that the flaw lives in Session Upload Progress is a guess: PHP has not confirmed it, the firm itself said it holds only so far as its own research matches PHP2Shell, and an independent code audit argues the specific bug others describe in that feature does not exist in released PHP. That audit is from an anonymous account and PHP's own code will settle it, but it is one more reason not to treat the setting as a shield.
Not everyone agrees. One vendor, Upwind, still lists the setting as an immediate mitigation, passing along another researcher's analysis rather than its own tests. watchTowr, which reproduced one of the flaws, says there is "no confirmed patch or workaround at this time."
If you already set it
No one is telling you to undo the change. The instruction is only not to count it as protection. PHP's own manual already advises turning the feature off where an application does not use upload progress bars, because the stored file names and field names "are not validated and may contain PHP code." If you turned it on by mistake somewhere that needs it, the only cost is that upload progress bars stop working.
Check that the change is actually in effect on the process that serves web traffic, not on the command line. The setting is INI_PERDIR, so it can be set in php.ini, .htaccess, or .user.ini.
A .user.ini file is read-only by the CGI and FastCGI versions of PHP, not by the Apache module, and PHP re-reads it only every 300 seconds by default, so a change there can take five minutes to apply.
Under the Apache module, use .htaccess or the server config. Confirm the value on PHP-FPM or mod_php, whichever serves your site, not on php -i at the shell.
If you can patch at 14:00 UTC
Get ready now. GMO Flatt's advice is to confirm your update steps and the checks you run afterward, rehearse any config change, and line up the people and approvals for a possible emergency restart. When the fix lands, update the runtime that serves web requests, which is PHP-FPM, mod_php, or CGI, not the application on top of it.
PHP issues fixes only for its four supported branches, 8.2 through 8.5. Which exact versions carry the fix and how far back the flaws extend will be announced with the release.
The Hacker News reported the branch support and the wider background in its earlier coverage of the disclosure.
If you cannot patch at once, or run an unsupported version
Where an immediate update is not possible, CERT-EU advises organizations to "consider isolating internet-facing applications from public networks until a fix can be applied." Banyard put the same point from inside the project: turning a server off for a day "might be the most sensible thing to do.
But that is far from a reasonable thing to demand for most people." Short of shutting down, restrict reach: put the site behind a VPN, allowlisted clients, or authenticated access at the edge, and check that traffic cannot reach the origin directly around those controls.
Shrink what an attacker gets if the server is taken over. GMO Flatt's other steps are to reduce the data stored on the server, reduce its privileges, remove stored credentials, including cloud roles, and ensure logging is enabled and kept in a secure location so you can investigate later.
Branches older than 8.2, including 8.1, 7.x, and 5.x, are end-of-life and receive no PHP fixes. For those, upgrade, take the system offline, or isolate it; a Linux distribution or hosting provider may backport a fix on its own schedule.
A web application firewall is a weak stopgap here, not a fix. Cloudflare added emergency "anomalous execution" rules on October 21, but its changelog names neither PHP nor these flaws; such rules only see traffic that passes through the provider, and they can miss variants.
If someone else runs your PHP
Updating WordPress, Laravel, or another application does not update the PHP runtime underneath it; that comes from your server package, host, or container image. On managed or shared hosting, ask your provider when a fixed PHP build will land and have them stand by.
Hosting providers build their packages only after PHP ships the fix: CloudLinux, for one, says its updated packages depend on the upstream release and will be posted when ready.
What to check when the release lands
No exploitation had been reported: watchTowr's FAQ listed none as of October 21, and these flaws were absent from CISA's catalog of known exploited flaws when it was last checked.
A short demonstration video was posted and then removed, and the audit above states that the circulating proof-of-concept code does not fire. Treat that as a snapshot that can change.
When the fix ships, check the fixed version for your branch, which versions PHP lists as affected, whether PHP confirms or rejects any setting as a mitigation, and whether the session code changed, which also answers the dispute over where the flaw lives.
The fixed versions and the advisory will appear on php.net and through PHP's GitHub security advisories, where the project assigns its own identifiers. After updating, review your logs for anything that happened before you patched.
