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.
Cloudflare says it is seeing early attempts to exploit the flaws, and has pushed emergency rules for sites behind it that it calls a stopgap until you patch. No compromise has been confirmed, the public exploit code going around has not been shown to work, and neither flaw is in CISA's catalog of known exploited flaws.
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.
Two people from the PHP project 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." Joe Ferguson, the release manager for the coming PHP 8.6, put it shorter: "ini settings won't save you."
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.
Some researchers point to a stronger stopgap than the session setting: blocking requests that carry a multipart/form-data body at the web server, before they reach PHP, because the suspected flaw is in how PHP reads that body. If you try this, block it for more than POST. PHP 8.4 added a function, request_parse_body(), that reads multipart bodies on other methods too, so a POST-only rule can be stepped around.
The cost is real: file uploads, and some forms that send multipart without a file, stop working until you remove the block. And like the session setting, this targets a suspected entry path, not a confirmed one, so it reduces exposure rather than guaranteeing safety.
A web application firewall is a stopgap here, not a fix, and Cloudflare says so itself. It has pushed emergency rules for the known exploit paths, free tier included, which its CTO calls "a STOPGAP only" ahead of patching. Such rules only see traffic that passes through Cloudflare, and they can miss new attack paths as they appear.
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.
One trap if you run PHP from a Linux distribution's packages: Debian, Ubuntu and similar backport security fixes into the version you already run instead of moving you to a new one, so a patched package can keep an old-looking version number. Do not judge whether you are fixed by the version string alone; check the package changelog for the CVE, or compare the exact package version against your distribution's advisory.
What to check when the release lands
Exploitation is early and unconfirmed. Cloudflare reports emerging attempts; watchTowr says it reproduced one flaw but has not reported attacks; the public exploit code going around has not been shown to work; and neither flaw was in CISA's catalog of known exploited flaws when it was last checked on October 21.
A researcher has posted a video said to demonstrate the exploit chain, and the audit above states that the circulating proof-of-concept code does not fire against released PHP. Treat all of this as a snapshot that can change by the hour.
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.
