PHP2Shell: Why Patching — Not the Config Toggle Your Host Is Pushing — Is the Only Fix

If you run a website, there is a good chance you got an email this week from your hosting provider telling you to disable a PHP setting called session.upload_progress. That is reasonable advice — but only as a stopgap, and only if you understand what it does and does not do.

This week brought two critical flaws in PHP itself, known together as PHP2Shell, that let an unauthenticated attacker run code on your server, and that security researchers report are already being targeted. The session.upload_progress switch is a genuine interim mitigation for one path of one of them — PHP recommends it by name. But PHP is equally clear that it is not the fix. In the words of PHP's own security advisory:

"Updating to a release containing the complete state reset patch is the only reliable mitigation."

So the real risk this week is not failing to flip a switch. It is flipping the switch, feeling covered, and never patching — leaving a remotely exploitable hole open behind a setting that was only ever meant to buy you a few hours. This guide separates the patch from the stopgap, shows you how to find the PHP version you are actually running, and gives you the exact patched release for your branch.

"PHP2Shell" is the name given to a pair of vulnerabilities in the PHP interpreter itself, both disclosed and patched on 21 October 2026.

CVE-2026-109618 is a memory corruption flaw in how PHP handles running out of memory. When an out-of-memory condition interrupts PHP while internal request data is only partly set up, later cleanup can treat that invalid data as if it were valid.

CVE-2026-109619 is a use-after-free flaw (CWE-416) where internal state from one request is retained between requests. State owned by one request can survive after its backing memory has been freed, and a later request handled by the same worker process can then use that stale state.

Three facts make this pair serious, and none of them are exaggerations:

• Both score CVSS v4.0 9.2 and allow unauthenticated remote code execution at web-worker privilege. An attacker does not need a login, a vulnerable plugin, or any specific application behaviour — they need only to reach a PHP server over the web.
• The bugs are in the interpreter, so any site on a vulnerable PHP version is exposed regardless of which CMS or framework it runs — WordPress, Laravel, Drupal, a custom app, or no framework at all.
• Exploitation attempts have already been reported — watchTowr reported observing them through its honeypot network on 21 October 2026. This is not purely theoretical.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating your application code, your theme, or your plugins does not fix these — the fix lives in PHP itself. Both flaws are documented in PHP's own security advisories: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp).

How far exploitation has actually gone is worth stating precisely, rather than reaching for "in the wild" and leaving it there. watchTowr reported observing exploitation attempts through its honeypot network on 21 October — real evidence, but vendor-reported. Rapid7 reported reproducing the flaws independently and expects a public exploit imminently. CISA issued an alert the same day urging immediate patching; as of its 23 October catalog update, though, the two CVEs are not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. That absence does not mean they are not being exploited — KEV has its own evidentiary bar and lags real-world activity. An unauthenticated RCE scored 9.2 with a working patch available warrants patching now regardless of catalog status. (KEV listing is also what sets federal remediation deadlines under CISA's Binding Operational Directive 22-01, so its absence matters for anyone with US federal exposure.)

CISA's alert also advises that anyone who cannot patch — or who is running PHP 8.1 or earlier, now past end-of-life and unsupported — should take their PHP systems offline until they can update.

Because the mitigation email is landing in so many inboxes, it is worth being precise about what that switch does.

One of the two flaws, CVE-2026-109619 (the use-after-free, where internal state survives between requests on the same worker), has a session-handling path that PHP's advisory addresses directly. Verbatim:

"For the session lifecycle case, set session.upload_progress.enabled=0 administratively and restart every worker."

Two things matter here. First: this is a real, PHP-recommended interim mitigation against one of the two flaws — not advice about some unrelated, hypothetical issue. If you genuinely cannot patch within the hour, do it. Second, and this is the part the hosting emails tend to leave out, the same advisory states its limit — the setting "does not mitigate the other lifecycle paths." It closes one door into CVE-2026-109619. It does not close the others, and it does nothing at all for CVE-2026-109618.

That is why PHP calls patching the only reliable mitigation, and why the switch buys you hours, not safety. Set it if you must, then patch — and do not let the switch become the reason you never got round to patching.

One more you may hear about: a further, narrower session-related issue (referred to as CVE-2026-115560) was reported on 23 October and calls for the same session.upload_progress.enabled=0 setting. We mention it only because you may see it cited in your provider's email — we could not find it in PHP's own security advisories at the time of writing, so treat any specific detail about it as unconfirmed until PHP publishes one. It does not change the advice above: patch.

Here is the whole situation on one screen. The left column is the fix. The right column is the stopgap. They are not alternatives.

The trap is simple to fall into: the email is about session.upload_progress, you change that one setting, and you conclude you have handled "the PHP thing". What you have actually done is buy a few hours against one path of one of the two bugs. If you do only one thing this week, make it the patch.

Everything downstream depends on one number: the PHP version serving your website. Here is how to find it, from most to least technical.

• Command line (if you have SSH access). Run php -v. The first line shows the version, for example PHP 8.3.31. Note that the web server may use a different version than the command line — see the caution below.
• Managed hosting / cPanel / Plesk. Look for a "Select PHP Version" or "PHP Settings" panel. It shows the active version and usually lets you switch.
• WordPress. Go to Tools → Site Health → Info → Server. The PHP version is listed there, no code required.
• A phpinfo() page. As a last resort, create a file containing <?php phpinfo();, load it in your browser to read the version, then delete it immediately. Leaving a phpinfo() page public is its own security problem.

Important caution: the version that serves web requests is the one that matters, and it is often not the same as the command-line version. Check the version reported by the web server (via Site Health, your host panel, or a short-lived phpinfo() page), not only php -v. Also check any secondary PHP that runs cron jobs, queue workers, or a staging site — each needs patching too.

Find your branch in the left column and update to at least the version on the right.

If you're on a supported branch (8.2 to 8.5): update to the patched release for your branch. On managed hosting this is often a version selector in your control panel; on a self-managed server it is a package update from your distribution or PHP repository. After updating, restart PHP-FPM (or your web server) and re-check the version the web server reports.

If you're on PHP 8.1 or earlier: these branches are past end-of-life and receive no official fix, so they remain vulnerable permanently. PHP published minimal source backports for 7.4, 8.0 and 8.1, but there are no official releases for them — meaning you need a backported package from your Linux distribution or LTS vendor, a rebuild from the source backport, or an upgrade to a supported branch. Per CISA's guidance, if you cannot do one of those promptly, take the system offline until you can.

If your host hasn't updated yet: ask them directly when they will apply the patched PHP release, and get a version number and a date. Managed PHP updates sometimes lag the upstream release or apply only to newly provisioned instances. If your provider cannot give you a specific patched version and date, treat your site as unpatched and plan accordingly.

In priority order:

• 1. Find your real PHP version — the one the web server uses, not just the command line. (See the section above.)
• 2. Patch to the fixed release for your branch — 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP calls this "the only reliable mitigation". Do it first, and restart PHP-FPM or your web server afterwards.
• 3. If you cannot patch within the hour, set session.upload_progress.enabled=0 and restart every worker — PHP's own advisory names this for the session lifecycle path of CVE-2026-109619. Know its limit: it "does not mitigate the other lifecycle paths" and does nothing for CVE-2026-109618, so it buys hours, not safety. A WAF can also reduce exposure to known exploit patterns as a stopgap. Then patch.
• 4. If you're on PHP 8.1 or earlier and cannot update, follow CISA's advice and take the system offline until you can move to a supported, patched branch.
• 5. If you're on managed hosting, get a written patch version and date from your provider, and re-verify the running version yourself once they say it's done.
• 6. Check your secondary environments — cron, queue workers, staging — and patch each.

The facts this week are serious enough on their own: two unauthenticated RCE flaws, scored 9.2, with exploitation attempts already reported and a patch available. The mistake to avoid is a comfortable one — changing a single setting, feeling covered, and leaving the real holes open. Patch first. Everything else buys time at best.