PHP2Shell Temporary Mitigations: What Buys Days and What Only Looks Busy

Sandbags are for the night of the flood

The PHP project's release notes contain one sentence worth taping to the monitor: "There are no complete mitigations, updating is the only safe choice." Its advisory then lists measures that, in its words, reduce exposure to specific attack paths but do not make an installation safe. That is an honest description of a sandbag. It keeps some of the water out. Nobody lives behind sandbags for a season.

So treat everything on this page as a bridge to the update, with a date at the far end. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the shared hosting and VPS and Docker guides cover getting there. If you do not yet know which PHP you run, the vulnerability check takes ten minutes. Then come back here only if the answer is "vulnerable, and stuck for now."

A mitigation is a promise to patch, written in configuration.

Where each setting cuts the chain

The two bugs work as a relay. An anonymous visitor sends a crafted request, usually a multipart upload, which PHP starts parsing before your application sees anything. Push PHP into an out-of-memory error at the wrong moment and internal request data is left half built (CVE-2026-109618). Or leave request-owned state pointing at memory that has already been freed, so the next request on the same worker picks it up (CVE-2026-109619). Either way the attacker's data ends up where PHP expected its own.

Read the diagram and the logic of the settings becomes plain. Removing the memory limit attacks the out-of-memory trigger. Smaller request bodies and fewer parts shrink the parsing step. Turning off upload progress closes the confirmed session paths. Restarting workers flushes any state already planted. Each one narrows a box. None of them removes the stale-state flaw underneath.

The PHP project's list, line by line

These come from the PHP project's October 21 advisory. Set them in the configuration that loads before a request is parsed: the main php.ini, the PHP-FPM pool file, or the Apache virtual host. Per-directory tricks arrive too late or can be overridden by the very code you are trying to protect.

Two more items from the advisory are code chores, not switches. Remove invalid or deprecated settings applied per request that print diagnostics before initialization. And fix the fatal errors and execution timeouts an outsider can trigger, including failures in callbacks, upload and import handling, and cleanup. If your error log is a wall of deprecation notices, this is the week to read it.

1. 1

   Open the pool or virtual host file

   On PHP-FPM, edit the pool file for the site, often named www.conf. On Apache with mod_php, edit the virtual host or the main server config.

2. 2

   Add the admin values

   Add `php_admin_value[memory_limit] = -1`, `php_admin_flag[session.upload_progress.enabled] = off` and the post size lines. Admin values cannot be changed later by the application.

3. 3

   Cap memory outside PHP

   Set a container or cgroup memory limit for the PHP service so an unbounded worker cannot take the whole machine with it.

4. 4

   Test the configuration

   Run the FPM config test (`php-fpm8.3 -t` on Debian and Ubuntu, `php-fpm -t` elsewhere) or `apachectl configtest` before restarting anything.

5. 5

   Restart every worker

   Restart the FPM service or Apache. A setting that only new workers see is a setting half the traffic ignores.

6. 6

   Confirm in phpinfo

   Load a password-protected phpinfo page and read the Local and Master values for each setting, then delete the page.

Shared hosting, a VPS and Docker each hide the switch somewhere else

On a VPS you own every file in the list above. On shared hosting you often own none of the ones that matter. Control panels tend to expose per-directory settings, which the PHP project specifically says not to rely on for upload progress, so the honest move is a support ticket asking the host to apply the advisory's server-level settings to your account, in writing, with a date for the real update. The template is on the shared hosting page.

In Docker, configuration baked into the image is the only kind that survives a redeploy. Copy an ini file into the image's PHP configuration directory and the pool settings into the FPM config, rebuild, and replace the containers. Set the memory cap on the container itself. Then put a reminder on the calendar to delete the workaround when the image moves to a patched base, because temporary settings in a Dockerfile have a way of becoming permanent architecture.

Firewall rules: the bouncer, not the lock

A web application firewall sits in front of the server and drops requests that look like the attack. According to Wiz Research, several edge and cloud companies (Cloudflare, Fastly, Google and Vercel among them) shipped ready-made protections and advice for teams that could not update right away. Google Cloud's advice covers Cloud Armor, its container services and App Engine. Cloudflare's own write-up says its protections were deployed automatically on all plans with the WAF turned on, Free included.

Two caveats decide whether the rule protects anything. First, a firewall only inspects traffic that passes through it. If the server's own address answers requests directly, an attacker can walk around the bouncer, so lock the origin to accept web traffic only from the firewall provider. Second, rules chase patterns, and patterns mutate. Cloudflare says plainly that customers should still patch PHP. When the company selling the bouncer tells you to change the locks, change the locks.

What none of this does

None of it cleans a server that was reached before you acted, either. Wiz showed that the bugs can also leak process memory without running code, and leaked memory can include passwords, tokens and API keys. If the server was exposed for days, read the signs of compromise and plan to rotate the secrets it could see. Our malware removal and security service handles the cleanup when there is something to clean.

Put a date on the duct tape

Attempts against sensors and honeypots began within a day of disclosure, most aimed at the upload-progress path. As of October 22, no confirmed compromise had been made public, which is a statement about one Thursday, not about next month. CrowdStrike's chief executive told CNBC on October 23 that the industry "will see a lot of breaches in coming months" from this vulnerability. Mitigations are measured in days. The problem is measured in months. Patching today costs an afternoon; a breach next spring costs a great deal more.

• Today: apply the settings above, restart every worker, and confirm them in phpinfo.
• Within 48 hours: get a written date for the PHP update from whoever runs the server.
• Within a week: run the update, test the site, and remove the workarounds you no longer need.
• After that: check for compromise, decide whether this site should still run PHP in public, and hand the next update to someone with a hosting and maintenance plan.

If the update keeps slipping because the site might break, that is a fixable problem. A WordPress site that falls over after a PHP update is a fixed $249 through Fix It Now, with work starting within one business day of payment and a full refund if we can't fix it. Our emergency fix applies these settings when the update must wait, then does the update. Sites stuck on end-of-life PHP get a plan. And if you would rather never repeat this week, a Next.js front end takes PHP off the public internet. The full map is on the PHP2Shell hub.