You can't completely block the two critical PHP vulnerabilities known as PHP2Shell before today's emergency patch, and the single configuration setting being shared on social media as a workaround isn't sufficient on its own, according to GMO Flatt Security, the Tokyo security firm that initially suggested it. PHP will release fixes at 14:00 UTC on October 21 for two flaws it rates 9.2 out of 10 on the severity scale, and has provided no workaround of its own. Until administrators can install the patch, what reduces risk is pulling exposed PHP systems off the internet or placing them behind access controls, limiting what a compromised server can reach, and preparing the update for immediate deployment the moment it becomes available.
The workaround circulating widely is a single line in a PHP configuration file: session.upload_progress.enabled=0. It disables Session Upload Progress, a feature that's turned on by default and tracks how far a file upload has progressed so a separate request can monitor it. GMO Flatt Security proposed the setting early on October 21, noting it couldn't confirm the change fully addressed the vulnerabilities but believed it would help with some probability. Hours later, the firm reversed course. In an update timestamped 14:00 Japan time (05:00 UTC), it stated the setting alone doesn't represent a complete fix and that attacks bypassing it are anticipated. Two members of the PHP project reinforced the point more directly. Replying to someone who proposed the upload-progress setting might patch the flaw, Gina Peter Banyard, a PHP core developer funded by the PHP Foundation, wrote: "The only thing I can say is that the only mitigation is patching / upgrading PHP." Joe Ferguson, the release manager for the forthcoming PHP 8.6, was blunter: "ini settings won't save you."
The setting can't be trusted for two reasons, according to the security firm. GMO Flatt anticipates a method to circumvent it but hasn't disclosed what that is. And the entire premise that the flaw resides in Session Upload Progress is speculation: PHP hasn't confirmed it, the firm itself said it holds only insofar as its own research aligns with PHP2Shell, and an independent code audit argues the specific bug others describe in that feature doesn't exist in released PHP. Cloudflare reports it's observing early attempts to exploit the flaws and has pushed emergency rules for sites behind its network that it describes as a stopgap until patching occurs. No compromise has been verified, the public exploit code circulating hasn't been demonstrated to work, and neither flaw appeared in CISA's catalog of known exploited vulnerabilities as of October 21. PHP hasn't disclosed which versions are affected, which component of PHP is involved, or whether any setting alters the risk; it says full details and fixed versions arrive with the release.
Where an immediate update isn't feasible, CERT-EU recommends organizations "consider isolating internet-facing applications from public networks until a fix can be applied." Banyard framed 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, the report advises restricting reach: place the site behind a VPN, allow-listed clients, or authenticated access at the edge, and verify traffic can't reach the origin directly around those controls. 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. PHP issues fixes only for its four supported branches, 8.2 through 8.5. Branches older than 8.2, including 8.1, 7.x, and 5.x, are end-of-life and receive no PHP fixes; for those, administrators must upgrade, take the system offline, or isolate it. The configuration workaround remains uncertain because nobody outside the group that discovered the flaws can test whether a given defense works until the release lands, which is why all current advice centers on lowering risk rather than guaranteeing safety. Organizations that can patch the moment the fix ships should use the hours before release to confirm update steps, rehearse any configuration changes, and line up personnel and approvals for a possible emergency restart—then apply the update to the runtime that serves web requests, whether that's PHP-FPM, mod_php, or CGI, not the application running on top of it.