You cannot completely block the two critical PHP flaws called PHP2Shell before today’s patch, and the setting passed as a workaround isn’t enough on its own, the security company that suggested it now says.
PHP will release the patch at 2:00 p.m. UTC on October 21 for two flaws rated 9.2 out of 10 and has not provided any workarounds of its own. Until you can install it, what reduces your risk is removing the exposed PHP from the internet or behind access controls, reducing what a compromised server can reach, and preparing the update to be applied as soon as it arrives.
No attacks have been reported. PHP has not specified which versions are affected, what part of PHP is involved, or if a setting modifies the risk; it indicates that all details and fixed versions are provided with the release.
At the time of writing this article, this version was not yet available. So no one outside the group that discovered the vulnerabilities can test whether a given defense works. This is why the advice below is intended to reduce risk and not to promise safety.
The setting you were asked to change is not a protection
The workaround that is spreading across social media and security blogs is a single line in a PHP configuration file: session.upload_progress.enabled=0. It disables session download progress, a PHP feature enabled by default, which records the download progress of a file so that another request can check it.
GMO Flatt Security, a Tokyo security company, suggested setting it up early on Oct. 21, saying it couldn’t be sure the change fully fixed the flaws but thought it would help with some probability.
Later that day, the company reversed that decision. In an update timestamped at 2:00 p.m. Japan time (05:00 UTC), it is stated that the setting alone does not constitute a complete fix and that attacks to circumvent it are expected. It instructs administrators to prepare their update, monitor attack traffic before release, and apply the patch as soon as it is released.
A senior PHP developer said the same thing more directly. Responding to someone who suggested that the download progress setting could fix the flaw, Gina Peter Banyard, PHP lead developer and PHP Foundation-funded documentation writer, wrote: “The only thing I can say is that the only mitigation is to patch/upgrade PHP. Unfortunately, I know too much. »
The parameter is unreliable for two reasons. GMO Flatt expects a way around this problem, but did not specify what it was. And the whole idea that the flaw lies in Session Upload Progress is just a guess: PHP hasn’t confirmed it, the company itself has said it only holds as far as its own research matches PHP2Shell, and an independent code audit claims that the specific bug others describe in this feature doesn’t exist in released PHP. This audit comes from an anonymous account and PHP’s own code will fix it, but that’s all the more reason not to treat this setting as a shield.
Not everyone agrees. One vendor, Upwind, still lists this 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 are “no confirmed fixes or workarounds at this time.”
If you have already defined it
No one tells you to undo the change. The instruction is only not to consider it as protection. PHP’s own manual already advises disabling the feature when an application doesn’t use download progress bars, because stored file and field names “are not validated and may contain PHP code.” If you accidentally enabled it somewhere that needs it, the only cost is that the download progress bars stop working.
Verify that the change actually takes effect on the process that handles 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 only rereads it every 300 seconds by default, so a change can take five minutes to apply.
Under Apache module use .htaccess or server configuration. Confirm the value to PHP-FPM or mod_php, whichever serves your site, not php -i at the shell level.
If you can patch at 2:00 p.m. UTC
Prepare now. GMO Flatt’s advice is to confirm your update steps and the checks you perform afterward, repeat any configuration changes, and align people and approvals for a possible emergency reboot. When the fix arrives, update the runtime that serves web requests, i.e. PHP-FPM, mod_php, or CGI, not the application that sits on top of it.
PHP fixes only its four supported branches, 8.2 through 8.5. The exact versions containing the fix and how far the flaws extend will be announced with the release.
Hacker News reported on the industry’s support and broader context in its earlier coverage of the disclosure.
If you cannot apply the patch immediately or run an unsupported version
When an immediate update is not possible, CERT-EU advises organizations to “consider isolating Internet applications from public networks until a patch can be applied.” Banyard expressed the same view within the project: turning off a server for a day “might be the most sensible thing to do.”
But that’s far from a reasonable thing for most people to demand. » Unless you shut down the site, limit the scope: place the site behind a VPN, allow-listed clients, or authenticated edge access, and verify that traffic cannot reach the origin directly around these controls.
Reduce what an attacker gets if the server is taken over. GMO Flatt’s other steps include reducing the data stored on the server, lowering its privileges, removing stored credentials including cloud roles, and ensuring logging is enabled and kept in a secure location so you can investigate later.
Branches prior to 8.2, including 8.1, 7.x, and 5.x, are end-of-life and are not receiving any PHP fixes. For those, upgrade, take the system offline, or isolate it; a Linux distribution or hosting provider can backport a patch on its own schedule.
A web application firewall is a weak stopgap here, not a solution. Cloudflare added emergency “abnormal execution” rules on October 21, but its changelog does not name PHP or these flaws; These rules only see traffic that passes through the provider and may miss variations.
If someone else runs your PHP
Updating WordPress, Laravel, or another application does not update the PHP runtime underneath; that comes from your server package, host, or container image. On managed or shared hosting, ask your provider when a fixed PHP version will arrive and leave it waiting.
Hosting providers only build their packages after PHP ships the patch: CloudLinux, for example, says its updated packages are version-dependent upstream and will be released when ready.
What to check when the release arrives
No exploits have been reported: watchTowr’s FAQ listed none as of October 21, and these flaws were absent from CISA’s catalog of known exploited vulnerabilities when it last checked.
A short demo video was posted and then removed, and the audit above indicates that the proof-of-concept code in circulation is not triggering. Treat this as a snapshot that can change.
When the patch ships, check the patched version for your branch, which versions PHP lists as affected, whether PHP confirms or rejects a setting as mitigation, and whether the session code has changed, which also addresses the dispute over the location of the flaw.
Patched versions and the advisory will appear on php.net and through PHP’s GitHub security advisories, where the project assigns its own credentials. After updating, check your logs for anything that happened before the patch was applied.
Gn bussni
