TL;DR: Patch PHP to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (whichever branch you run) now. Both CVE-2026-109618 and CVE-2026-109619 are unauthenticated RCE at CVSS 9.2. If you can't patch immediately, apply the research-published mitigations and consider isolating exposed hosts. End-of-life PHP 5 and 7 have no patch — migrate or take them offline.
PHP2Shell is the name researchers have given to a pair of critical vulnerabilities in the PHP interpreter itself — not a framework or a plugin, but the engine that runs a large share of the web. Tracked as CVE-2026-109618 and CVE-2026-109619, both carry a CVSS v4.0 base score of 9.2, and each can lead to unauthenticated remote code execution: an attacker who can reach a vulnerable PHP endpoint may be able to run their own code on the server without any credentials. PHP released fixes on 21 October 2026. Because write-ups and, by some accounts, an exploit tool are already public, the window between disclosure and mass exploitation is short — this is a patch-today situation.
What PHP2Shell is
Two memory-safety bugs in the PHP interpreter's internal request handling can be driven to a state the engine never intended, and that state is exploitable for code execution. Because the flaws live in the interpreter — below your application, your framework and your own code — no amount of secure coding in your app protects you if the underlying PHP version is vulnerable. That is what makes an interpreter-level RCE so serious: it is broad, it is unauthenticated, and it is indifferent to how carefully the application on top was written.
The two flaws
| CVE | CVSS | Root cause (high level) |
|---|---|---|
| CVE-2026-109618 | 9.2 | RCE via out-of-memory corruption — OOM handling can interrupt PHP while internal request data is only partially initialized. |
| CVE-2026-109619 | 9.2 | RCE via stale global state — request-owned internal state can survive after its backing memory has been freed. |
Both are classic memory-lifecycle problems: data that is used before it is fully set up, or after it should have been torn down. We are deliberately keeping this high level — there is no proof-of-concept or exploitation recipe here, because a live, public exploit already arms attackers, and our job is to help defenders close the gap, not widen it. For the technical internals, see the research write-ups linked below.
Who is affected
The fixes ship in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; upgrade to at least the fixed release on your branch. Two caveats matter:
- The back-reach is disputed. Some reporting states that PHP 5.4.0 and later are vulnerable, while other researchers note the official vendor advisory has not confirmed the PHP 5 / PHP 7 scope. Treat the broad claim as plausible until ruled out.
- End-of-life branches have no patch. The fixes cover only the 8.2–8.5 branches. Any server still running PHP 5 or 7 should be assumed at risk and prioritised for migration or isolation, because no fix is coming for it.
The practical scope is enormous: PHP runs a large fraction of the web, often several versions behind, and frequently on hosts nobody is actively tracking — which is exactly where this kind of flaw lingers longest.
Is it being exploited?
Reports conflict, and we will not overstate it. At disclosure, some teams said they had not yet seen exploitation in the wild; others flagged it as already exploited and pointed out that technical write-ups and an exploit tool are public. When an unauthenticated RCE on an internet-facing interpreter has a public exploit, the honest planning assumption is that mass exploitation is imminent, not hypothetical — national cyber authorities have urged organisations to consider taking offline any system that cannot be fixed right away. Patch on that assumption; do not wait for your own logs to confirm it.
What to do in the first 24 hours
- Patch now. Upgrade PHP to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 on every host. On managed platforms, confirm the patched runtime is actually deployed, not just released.
- If you can't patch immediately, apply the temporary mitigations published in the research advisories, and for anything you can't fix quickly, follow national guidance and consider isolating or taking it offline until you can.
- Inventory every host running PHP — production, staging, legacy, and third-party appliances that bundle it. You cannot patch a server you have forgotten you run.
- Verify the running version, not the intended one. The risk is the PHP build actually serving traffic; drift between "what we deploy" and "what's running" is where these windows stay open.
- Watch for signs of compromise on anything that was internet-facing and unpatched during the exposure window, and assume the worst for any end-of-life host that was reachable.
How to confirm your real exposure
The hardest part of an interpreter-level CVE is not the patch — it's knowing where you run the vulnerable version. A fast version check on the hosts you know about is step one. Step two is the one teams miss: the internet-facing PHP services you've forgotten — an old marketing site, a staging box that drifted public, a third-party appliance. An external view of your attack surface is what surfaces those.
This is where continuous testing earns its keep. AssurePort's network and host penetration testing discovers exposed services, fingerprints their versions, and correlates them against known-exploited vulnerabilities — so a newly-weaponised CVE like PHP2Shell is checked against your real external footprint, including the hosts you don't have on a list. It's the same reason we argue that cadence beats a once-a-year snapshot: the dangerous window is the days between a public exploit and your patch, and only continuous testing covers it. We wrote about exactly this dynamic in patch prioritisation with the CISA KEV catalog and zero-day response: the first 24 hours.
Sources & further reading: PHP's official advisory is the authority on affected and fixed versions. Independent analysis: Sansec, watchTowr, Help Net Security and SecurityWeek. Where these disagree (back-reach to PHP 5/7, exploitation status), we've said so above rather than pick a side.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the nickname for two critical PHP interpreter vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2, each allowing unauthenticated remote code execution. PHP shipped fixes on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Which PHP versions are affected and fixed?
Upgrade to at least 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 on your branch. Patches cover only 8.2–8.5. The reach back to PHP 5/7 is disputed and unconfirmed by the official advisory; no patch exists for those end-of-life branches, so treat them as at risk.
Is PHP2Shell being exploited in the wild?
Reports conflict — some say not yet observed, others flag active exploitation, and technical write-ups plus an exploit tool are public. With unauthenticated RCE and a public exploit, plan for imminent mass exploitation and patch now.
What should I do right now?
Patch to the fixed version immediately. If you can't, apply the published mitigations and consider isolating exposed hosts. Then inventory every host running PHP and verify the version actually deployed — the risk is what's running, not what you think you run.