PHP2Shell: what we know about CVE-2026-109618 and CVE-2026-109619

On 21 October 2026 the PHP project shipped an emergency release for two bugs that let an unauthenticated attacker run code on a server. PHP runs about 69 percent of the websites whose server language anyone can identify¹. So when CISA, the UK's NCSC and CERT-EU all told people to patch or take the system offline^{2, 3, 4}, governments from the Netherlands to Australia did exactly that to some of their own sites^{5, 6}.

I read PHP's advisories, the write-ups from the three teams that found the bugs, the commit that fixes them, a dozen vendor posts and the government alerts. This post pulls that together. It has nine charts and a numbered reference for every claim that needs one.

The research cut-off is 22 October. The story is still moving, so check the references before you act on anything here.

The short version

The bugs	CVE-2026-109618, "RCE via OOM corruption"7. CVE-2026-109619, "RCE via stale global state"8.
Who is affected	Any PHP version from 5.4 up, as far as the vendors say9, 10. Apache with mod_php is the worst case11.
Needs a login	No. The request comes over the network and needs no user interaction7.
Fixed in	8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October. Source-only backports exist for 7.4, 8.0 and 8.1. Nothing from upstream for 7.3 and older11.
Attacks	Attempts since 17 October12. No published, confirmed breach yet. CISA's catalog lists neither CVE13.

The severity score depends on who you ask, and the spread is wider than you would expect for one pair of bugs.

PHP's own CNA scores both at 9.2 on CVSS v4.0, and NVD says 9.8 on CVSS 3.1¹⁴. Red Hat, SUSE and Amazon Linux say "Important" at 8.1. Red Hat's argument is that reliable exploitation needs precise heap work, and that its default PHP-FPM setup exits workers on early-init failure¹⁵. The 10.0 that circulated on 20 October was wrong¹⁶. I would plan around the high scores. A vendor rating tells you about its own build, not about the PHP binary you installed by hand.

What broke

Both bugs come from one habit. When PHP runs out of memory mid-request, it aborts with a longjmp, which internally is zend_bailout. The jump skips whatever the interrupted code was doing. Request shutdown then cleans up whatever state it finds^{7, 8}. Half-built state looks like finished state, and PHP trusts it.

CVE-2026-109618 is the first version of that mistake. An out-of-memory error interrupts PHP while request data is only partly set up, and cleanup treats the invalid data as valid⁷. CVE-2026-109619 is the second. Request-owned state survives after its memory is freed, and a later request on the same worker uses it⁸.

PHP's advisory is blunt about mod_php. An unauthenticated request "can trigger the attack before any application code runs"¹¹. There is no plugin to audit and no application code to blame, and a WAF written in PHP never sees the request.

Wiz found four separate bugs under the two CVEs and demonstrated unauthenticated code execution against the stock WordPress, Drupal and Joomla container images⁹. The chart below scores them on six things a defender cares about. Read each line left to right.

The memory leak is the one that makes the rest practical. Wiz says a leftover pointer lets the next multipart request copy reclaimed heap memory into a PHPSESSID response cookie, even if the application never calls session_start()⁹. JPCERT/CC lists abnormally long or malformed PHPSESSID cookies among its indicators¹⁷. If a host was exposed, assume that any secret that passed through its workers could have been read. That includes session cookies and API keys, not only what sits on disk.

Sources disagree on which CVE covers which of Wiz's four bugs. Wiz's blog table, Wiz's own php2shell.com and PHP's advisories all differ in places. I use PHP's mapping, since one release fixes everything. It only matters when a scanner or ticket calls one CVE "the info-leak one".

They also disagree on affected versions. The CVE records list 8.2 and up, yet PHP shipped backports for 7.4, 8.0 and 8.1, and Google and Wiz say 5.4 through 8.5^{11, 10, 9}. I treat everything from 5.4 up as affected until someone shows me otherwise.

How the fix works

The fix commit is by Arnaud Le Blanc, authored on 18 October. It adds a soft memory limit that queues the usual error instead of jumping out mid-allocation. It also adds a hard limit that prints "Hard memory limit exhausted" and calls _exit(137) with no shutdown handlers. The new INI setting is memory_hard_limit_percent, which defaults to 200 percent of memory_limit, or the limit plus 1 GiB when the limit is above 1 GiB¹⁸. An engine change this deep brings regressions, and the project filed one against the hard exit within hours of the release¹⁹.

Who knew, and when

The bugs are old. Bug 78876, an out-of-memory crash on long multipart variables, was filed in 2020 and left alone because nobody had shown it was exploitable²⁰. A 2024 audit saw the first signs, and competing fixes stalled for months^{16, 21}.

The recent timeline starts on 30 July, when Calif began a PHP audit. Calif reported an unconditional code execution bug on 11 August, and OpenAI reported the same root cause the same day. Wiz found its first bug on 19 August, reported on 24 August and heard back from PHP on 21 September^{16, 20, 9}.

Then the embargo came apart in three places. The CVE IDs leaked around 15:00 UTC on 20 October with the wrong score. Calif posted a proof-of-concept video by mistake. Chainguard shipped fixed container images at 07:41 UTC on 21 October, more than six hours before the coordinated release, and anyone could diff them against the old ones¹⁶. Cloudflare reported early attacks at 07:43, two minutes after those images went public. Nothing I read links the two, so treat the timing as an observation, not a finding.

Is anyone being attacked?

Yes, there are attempts. Nobody has published a confirmed breach. Both statements are true at once.

Reported. Amazon's MadPot honeypot logged the first attempt on 17 October, four days before disclosure. Amazon says the bugs are now "broadly exploited" and adds that it is "unclear if any of these attempts would have succeeded"¹². ELLIO logged a first request at 08:36 UTC on 21 October, a Mirai-style loader at 14:38 and a web-shell write at 23:08²². VulnCheck's canaries caught scanners with php2shell-scan user agents, and one attempt to plant a web shell through the upload-progress session file. That attempt failed²³. Arctic Wolf saw id checks followed by wget pulls, with Mirai-derived botnet samples on the other end. It says its data does not show any sample running²⁴. watchTowr says its honeypots saw exploitation from 21 October, with no payloads or paths²⁵.

Reported, the other way. CISA said it had not observed exploitation, and its catalog lists neither CVE^{2, 13}. Bitdefender saw no attempts in its own telemetry²⁶.

Reported, and new. VulnCheck says it has a working exploit for CVE-2026-109618 on x86-64 with ASLR on, for PHP 8.4.10 through 8.4.26. On ARM64 the leak works but code execution does not yet. It sells the exploit to its own customers, so nobody outside can check it²³. Earlier reports said exploitation needed ARM64 or ASLR switched off²⁷. That is no longer the safe assumption.

My analysis. Scanning and attempts are certain, and plenty of vendors see them. A published confirmed compromise does not exist yet. That is weak comfort, because a successful hit can return HTTP 200 with no crash²⁸ and the memory leak leaves almost nothing behind. The agencies that say "none observed" mean a confirmed breach. The ones that say "aware of reports" are counting honeypot attempts. Both are right.

In ATT&CK terms the traffic so far is T1190, exploiting a public-facing application, then T1105, ingress tool transfer, and in one case T1505.003, a web shell²⁹. Those are my labels.

One warning. Hundreds of proof-of-concept repositories appeared on GitHub within hours, and VulnCheck says very few are legitimate exploits²³. Some are pranks²⁶. Don't run any of them on a machine you care about.

How big is the exposure?

Depends who counts, and what.

VirusTotal found about 5.1 million PHP IP addresses. About 1.1 million disclose a version, with roughly 272,000 on 8.2 to 8.5 and roughly 758,000 on end-of-life releases³⁰. VulnCheck counts 2,608,039 PHP hosts. Of those, 1,474,985 advertise a version older than the fixed build and 1,133,054 hide it entirely²³.

The hidden ones worry me most. A server that hides its version cannot be scored from outside, and it is the kind of server that gets forgotten. Distro builds also keep old version strings after they are patched, so an old number does not always mean a vulnerable host³¹.

The same VulnCheck data names the applications behind the hosts it could identify.

WordPress is the elephant at 469,699 hosts. Laravel is the surprise at number two with 124,866²³. VirusTotal puts WordPress nearer 538,000³⁰, so even the application counts depend on the method.

The totals do not line up either. One source says 1.5 million, another says 22.6 million.

They count different things. VirusTotal counts IPs. VulnCheck counts hosts. Modat counts services. Unit 42 counts instances³², and Shodan splits its count between versions³³. Pick one unit before you compare any two of these.

How the fix reaches you

Three finders, one security team and a long list of downstream builders. The widths in this diagram are illustrative, but the shape is real.

The patched 8.2 to 8.5 releases fan out fast. Older branches get a backport at best, and 7.3 and older get nothing from upstream. Here is where the main platforms stood on the morning of 22 October. It changes hourly.

A lot of this was prepared before anyone outside the room could read the advisory. Wiz thanks Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft and Vercel for pre-disclosure work⁹. OpenAI says it also briefed ONCD and CISA⁴².

I think that part worked. The part that did not work was keeping it quiet. Vendors, finders and governments held a secret for weeks, then lost it in about a day.

What the governments said

Every agency says to patch now. They split on three things, and the chart shows how. Hotter cells are stronger statements.

CISA and the FBI say to take the system offline if you cannot update^{2, 43}. The UK's NCSC says to consider it³. NCSC New Zealand is "aware of reports of active exploitation"⁴⁴, while Canada identified a proof of concept but no active exploitation⁴⁵ and Singapore reports widespread attempts⁴⁶. JPCERT/CC warns that attacks may leave no trace in logs¹⁷. Some governments acted on their own sites. Wikimedia took tools offline⁴⁷. The Dutch government pulled several sites⁵, and in Australia the ABS and Jobs and Skills Australia went offline^{48, 6}.

AI on both sides

Every team that found these bugs says AI helped. Calif used an LLM companion and an agent for source review²⁰. Wiz used its Atlas researcher with Gemini 4 Argon and GPT-5.6 Sol, and says one researcher did in a week what would have taken a world-class team months⁹. OpenAI says that, to its knowledge, frontier AI found the bugs before attackers did⁴².

That is a claim about the finders, and it is plausible. I have not found published evidence that attackers used AI on the exploits. watchTowr called the early proof-of-concepts "vibecoded", which is an impression, not forensics⁴⁹.

The cost shift is what I take from it. The PHP Foundation says its volunteer security team has handled 15 CVEs and more than 100 invalid or duplicate reports since 1 July¹⁶. AI finds bugs faster, and open-source maintainers are the ones who triage the pile.

OpenAI also asks a question I want to flag. It asks when governments or operators should use a vulnerability to patch systems they are authorised to manage after losing administrative access. It floats "internet-wide always-on scanning" that either notifies owners or patches the system⁴². It is a proposal for comment. I would want a clear answer on consent and liability before anyone builds it.

What I would do on day one

1. Inventory every PHP runtime. Include PHP inside appliances and vendor products. NCSC-NL keeps a cross-vendor list⁵⁰. Check the version inside each container, and read the package changelog before you trust a version string.
2. Patch, then restart every worker. The window closes when the worker restarts, not when the package installs⁵¹.
3. If you cannot patch today, take it offline. That is what CISA, NCSC and CERT-EU say^{2, 3, 4}. The alternative is PHP's interim settings, which are session.upload_progress.enabled=0, memory_limit=-1 that apps cannot override, a low post_max_size and a cgroup cap per worker. Skip RLIMIT_AS, which can trigger the vulnerable path. PHP says plainly that none of this makes an installation safe¹¹.
4. Hunt back to 17 October. Look for "Unknown on line 0" memory errors, Apache's AH00052 crash entries, very large multipart requests, odd PHPSESSID cookies, and shell processes whose parent is the web server or PHP-FPM^{26, 12}. Preserve logs before you upgrade³.
5. Rotate secrets that passed through PHP memory. That means session keys, framework app keys, WordPress salts, database credentials and upstream API tokens.
6. Leave the public proof-of-concepts alone. Detection works better from the behaviour side, such as a web server spawning a shell⁵².

The Australian angle

ASD's ACSC says all PHP versions from 5 onwards may be affected, and that it was not aware of successful exploitation in Australia⁵³. If your PHP host held personal information and you find signs of compromise, the Notifiable Data Breaches scheme applies. You have 30 days to assess whether it is an eligible breach, and if serious harm is likely you notify the OAIC and the people affected⁵⁴. The memory-disclosure bug makes credentials of users who logged in during the exposure window a realistic category to assess. Other regimes, such as ransomware payment reporting and critical-infrastructure rules, run their own clocks, so check yours.

What is still open

• Will a public exploit follow VulnCheck's, and will it reach other branches?
• Has any vendor confirmed a real compromise?
• How complete is the fix? Researchers on oss-security raised incomplete-fix claims for 8.5.12, and PHP called them unrelated.
• How exposed are RoadRunner, Swoole and the CLI? I found no source that addresses them.
• Does PHP-FPM allow a full exploit? The advisory says no complete FPM chain was shown for CVE-2026-109618, while Wiz and the Foundation say FPM was confirmed through application-level code paths^{7, 16}.