On October 21, 2026, the PHP project shipped an out-of-cycle security release for two critical vulnerabilities that researchers have named PHP2Shell — CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 (Critical) by PHP’s security team. Both are unauthenticated remote code execution flaws, and — this is the part that makes them a genuine all-hands event — both live in PHP’s core, not in any single application. The same interpreter runs WordPress, Drupal, Joomla, Magento, and countless custom and internal applications, so a single flaw in it has an enormous blast radius.
PHP has been explicit about one thing: there is no complete mitigation. Updating is the only safe choice. The interim configuration tweaks reduce exposure to specific paths, but they do not make an unpatched installation safe.
If you run PHP anywhere — and most organizations do, often in places they have forgotten about — this post is a working response plan. We will cover what the flaws are at a conceptual level (without anything that helps weaponize them), why the leaked-ahead-of-embargo disclosure compressed everyone’s timeline, why finding all your PHP is harder than patching it, and the concrete steps to take now and after. The sourcing here is PHP’s own advisory as summarized by Picus Security, with disclosure-timeline and exploitation detail from The Register and Ubuntu’s security team.
What Happened, and the Leak That Moved the Clock
The PHP Foundation had run a coordinated vulnerability disclosure with distributors and set a public disclosure date of October 22, 2026 at 14:00 UTC. That plan did not survive contact with the internet.
On October 20, a now-deleted post on a public tech forum claimed two PHP RCE flaws were headed for disclosure, scored them CVSS 10.0, and said they affected every version from PHP 5 onward — on no evidence beyond, as the post itself put it, “trust me.” Screenshots spread. Within hours, researchers confirmed the flaws were real and under embargo. PHP responded that evening by pulling its release forward a day, to October 21, reserving the right to ship even sooner if details leaked further or exploitation appeared.
Two useful corrections came out of that scramble. The leaker’s “CVSS 10.0” was a guess; PHP’s own rating is 9.2. And critically, the leak carried the existence of the flaws but not how they work — which bought defenders a narrow window. That window is now the whole game, because exploitation attempts started immediately:
- Amazon reported that its honeypot systems recorded an exploitation attempt on October 17 — four days before public disclosure, indicating at least one actor had the details early.
- Cloudflare observed attempts climbing from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22, including campaigns attempting to deploy a Mirai botnet variant.
The reassuring nuance, as of this writing: these amount to mass scanning and probing rather than confirmed code execution. Researchers note a reliable exploit is proving harder to build than expected. That is not a reason to relax — it is the reason the patch window matters. You are racing the moment a dependable exploit appears, not the scanning that is already here.
What Kind of Bugs These Are
PHP’s advisory is clear that these are two distinct vulnerabilities, not one bug with two numbers. Both sit in PHP core, both can be reached by an unauthenticated web request, and both end in remote code execution — but they work differently. We will keep this conceptual; the goal is to help you reason about exposure and detection, not to hand anyone a recipe.
CVE-2026-109618 — RCE via out-of-memory corruption. In vulnerable versions, an out-of-memory error can abruptly interrupt request processing while internal request data is only partially initialized. Cleanup routines may then act on that invalid data, which can lead to code execution. PHP’s advisory rates the risk highest for the mod_php setup, where a demonstrated exploit can trigger the flaw before any application code runs — meaning your application’s own logic and auth give you no protection, because the attacker never reaches them.
CVE-2026-109619 — RCE via stale global state. A PHP worker handles many requests in a row. Internal state from one request can survive after the memory behind it is freed; a later request on the same worker may then use that stale state before normal initialization resets it. PHP confirms paths involving session.upload_progress and, on PHP 8.5, the fatal-error backtrace feature — but is explicit that these are not the only ones. Notably, the stale state can be created by a fatal error or execution timeout inside application code, which is why PHP’s guidance includes fixing those, not just flipping configuration flags.
Two properties make these critical rather than routine. First, they are in the interpreter itself, so a single flaw affects every application the interpreter runs — the blast radius is the entire PHP estate, not one app. Second, no authentication is required: the attacker controls the whole request, so there is no login, upload form, or application entry point they need to get past.
The Hard Part Is Not Patching. It Is Finding All Your PHP
Here is the operational truth that separates a clean response from a painful one. Applying the patch is easy. Knowing everywhere the patch needs to go is not.
First, the version picture
PHP shipped fixes for its four supported branches. The action for every one of them is the same: update now.
| PHP branch | Status | Fixed version | Action |
|---|---|---|---|
| 8.5 | Active support | 8.5.12 | Update now |
| 8.4 | Active support | 8.4.27 | Update now |
| 8.3 | Security fixes only | 8.3.36 | Update now |
| 8.2 | Security fixes only (EOL Dec 31, 2026) | 8.2.35 | Update now |
| 8.1 | End of life | Source backport only | Rebuild or upgrade |
| 8.0 | End of life | Source backport only | Rebuild or upgrade |
| 7.4 | End of life | Source backport only | Rebuild or upgrade |
| 7.x / 5.x | End of life | No project backport | Upgrade or isolate |
For end-of-life branches, PHP took the unusual step of publishing minimal source backports for 7.4, 8.0, and 8.1 — but there are no packaged releases, so anything older than 8.2 needs a backport from your distribution or LTS vendor, a rebuild from source, or an upgrade. One rapid-response scan on October 20 counted roughly 884,000 internet-facing hosts reporting PHP 8.1 or older — about 59% of those reporting any version at all. Those are banners, not confirmed-vulnerable systems, but they map the scale of the EOL problem.
Then, the inventory problem
This is where teams get hurt. PHP hides in places that do not look like “a PHP server”:
- CMS platforms — WordPress, Drupal, Joomla, Magento. Internet-facing, PHP by default.
- Hosting panels — cPanel, Plesk, shared hosting, often running several PHP versions side by side, some end-of-life.
- Vendor appliances — products that bundle PHP inside, easy to miss entirely in an inventory.
- Windows software — applications that ship
php.exeorphp-cgi.exewithout ever presenting as a web server. - Internal tooling — dashboards, legacy intranet apps. Frequently unpatched, frequently EOL, frequently forgotten.
And a trap worth repeating: a version check on a workstation can show a patched build while the PHP-FPM pool actually serving production runs a different, vulnerable binary. Check what each site actually executes, through a protected diagnostic endpoint — not just what php --version says on the box.
The Remediation Plan
Patch
- Install the fixed build — 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or your distribution’s patched package (distros were pre-notified and had packages ready).
- For 7.4 / 8.0 / 8.1, apply your LTS vendor’s backport or PHP’s minimal source backport, then plan the upgrade off end-of-life PHP entirely.
- Restart affected services, or use a verified reload that replaces the PHP binary and every worker. A half-reloaded pool can keep serving the vulnerable binary.
- Verify what each site actually runs through a protected diagnostic endpoint, and confirm the installed package includes both fixes. A command-line version check alone is insufficient.
If you cannot patch this minute
PHP published interim settings (limits on request size and multipart parsing, disabling session.upload_progress, disabling fatal-error backtraces on 8.5). Treat them as temporary exposure reduction, not safety — PHP is explicit that none of them make an installation safe. Apply them to buy hours, then patch. Keep any proxy-level request-size limits you add afterward; they are good hygiene regardless.
Assume the window was open
Patching does not evict anyone who got in before you patched. Because exploitation attempts predated disclosure, treat recently-exposed, unpatched PHP as potentially touched and check for:
- New or modified
.phpfiles in web roots and upload directories (web shells). - Unexpected cron jobs, processes, or users.
- Outbound connections from the web-server user — a native-code payload can open a socket without ever spawning a shell, so watch the network, not just process trees.
- Crash and OOM patterns in logs: bursts of
SIGSEGV/SIGABRTin php-fpm, “Segmentation fault” in Apache error logs, worker respawns, orAllowed memory size ... in Unknown on line 0.
If anything looks off, rotate every secret the web-server user could read — database credentials, API keys, application keys, session secrets. This is the step teams skip and regret.
Detect going forward
Detection for this bug class has to sit below the application, because confirmed mod_php attacks happen before application code runs. Watch what the PHP process spawns: alert when php-fpm, php-cgi, apache2/httpd with mod_php, lsphp, or frankenphp launch shells, interpreters, or network tools (curl, wget, nc, socat). On Linux, an auditd execve rule scoped to the web user’s UID, or Falco/Tracee, gives you this cheaply; on Windows, Sysmon Event ID 1 filtered on ParentImage. Baseline first — convert, git, and wkhtmltopdf are often legitimate children — and forward logs off-host so a compromised account cannot tamper with them.
The Lesson Under the Patch
Patch management is the fix for PHP2Shell. But the reason one organization spends an afternoon on this and another spends a fortnight is not patching speed — it is inventory and prioritization. The teams that moved fast were the ones that could answer, within minutes: where is PHP running, which versions, which of those are internet-facing, and what sits behind the exposed ones.
That is the muscle worth building, because PHP2Shell is not the last critical RCE in a ubiquitous component. A flat list of “every host that has PHP” is not enough; what you need is the exposed, internet-facing, EOL instances ranked first, correlated with the identities and data they could reach if compromised. That is the difference between a CVSS 9.2 finding and a real, prioritized risk — a theme we have written about in why flat per-rule severity is broken and why isolated findings mislead you.
This is also the honest place for us to mention where a platform helps and where it does not. No tool patches PHP for you. But a CSPM and asset-inventory layer that can quickly surface which workloads run a vulnerable, exposed PHP — and an attack-path view that shows what each of those boxes could reach into your cloud — turns the inventory scramble into a query. If knowing your exposure fast is the bottleneck when a CVE like this lands, that is the gap worth closing before the next one.
The Takeaway
PHP2Shell is a serious pair of flaws handled, so far, about as well as these things can be: coordinated disclosure, same-day patches across four branches, and — thanks to the leak carrying the existence but not the mechanics — a real window for defenders to get ahead of a working exploit. Use it. Patch the supported branches now, hunt down the PHP hiding in appliances and EOL corners, and assume the pre-disclosure window means some exposed systems were probed.
And when the dust settles, take the real lesson: the organizations that sailed through did not patch faster, they knew their estate better. Build that inventory and prioritization capability now, while this one is fresh, and the next critical RCE in a ubiquitous component becomes a routine Tuesday instead of a fire drill.
