The PHP vulnerability called PHP2Shell is two critical flaws in the PHP engine itself, fixed in an emergency release on October 21, 2026. PHP runs an estimated 70% of websites according to the Guardian and Wiz, so the question for a developer is simple: which copies of PHP do you run, and are they patched? The better story is how the bug waited two years for a decision, how the embargo leaked, and why sources disagree about exploitation.
TL;DR
- PHP2Shell covers CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0 by the PHP team. Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 7.4, 8.0 and 8.1 got source patches only.
- The flaws sit in memory and error handling, which nearly every request touches. On Apache with mod_php the first one can run before any application code, so a login page cannot stop it.
- A PHP core developer saw the first signs in a 2024 audit. Competing fixes had trade-offs and a consensus-based security team struggled to choose. The PHP Foundation calls the delay a structural failure.
- Amazon logged an attempt on October 17, four days before the patch. CISA had not observed exploitation at publication, and several analysts say many public exploit scripts do not work. Patch anyway.
- The same day GitLab shipped a critical patch release, and a New Mexico court ordered Meta to pay $25 billion.
What is the PHP vulnerability called PHP2Shell?
PHP2Shell is the nickname for two flaws that let an unauthenticated stranger run code on a server through ordinary web requests. The official advisories are GHSA-w8hw-w9fx-j79w for CVE-2026-109618, titled "RCE via OOM corruption", and GHSA-6wmf-4rv5-p3rp for CVE-2026-109619, titled "RCE via stale global state". The earliest affected code path dates to PHP 5.4.0.
PHP is a scripting language that builds web pages on the server just before they reach the visitor. It is over thirty years old, and WordPress, Drupal and MediaWiki are written in it. The Guardian describes the nonprofit PHP Foundation as having about thirteen full-time and part-time engineers, which matters for the rest of the story.
Wiz points out that the problem sits in PHP itself, below whatever application runs on top. Even a hello world script on an affected version is exposed, so the WordPress, Drupal and Joomla demonstrations are examples.
How does PHP remote code execution work here, in plain words?
No exploit steps appear here. The mechanism is explained at the level the PHP advisories use.
The first flaw starts with memory limits. Every PHP request gets a memory budget. If a request hits that limit at exactly the wrong moment, PHP exits the current work in a hurry and can leave the request memory half built. The cleanup step may later read or branch on that half-built data. On Apache with mod_php the cleanup runs even when request startup failed, entirely before application code begins. PHP-FPM removes the child when startup fails, which blocks that path, although the advisory says FPM is still susceptible through other routes.
The second flaw is a leftover. A worker keeps some global state between requests, such as error, session and object state. A fatal error can abandon an operation before it resets that state, so the worker holds a pointer to memory that belonged to the previous request. A later request handled by the same worker can then use that stale pointer before normal initialization replaces it.
The fix removes PHP's emergency exit for running out of memory. Instead of bailing out of the middle of a request, PHP now schedules a graceful stop at the next safe point, and it only hard-stops past a second, higher threshold. Both advisories say updating to a patched release is the only complete mitigation. Partial measures exist, and PHP's team says they only reduce exposure.
Why did a known PHP memory bug wait two years?
The PHP Foundation's post-mortem is unusually frank. In 2024 PHP had its first external security audit in years, funded by the Sovereign Tech Agency and carried out by Quarkslab. While fixing one reported issue, a Foundation-contracted core developer found the first signs of the out-of-memory problem. A potential exploit was theorized, but no concrete vector was found and other issues with clear impact took priority.
Fixing it was hard. Each competing approach had a cost: broken backward compatibility, new denial-of-service risk, or changes to many third-party extensions. The team decides by consensus and, in the Foundation's words, "struggled to choose between these and feared the repercussions of shipping the wrong choice." Work stalled and restarted for months. The Foundation says plainly that the delay was a structural failure caused by the decision process and a lack of resources, and that the team is moving to majority decisions and bringing leadership in sooner on hard trade-offs.
Who found PHP2Shell, and did AI find it?
In August, finders arrived within days. Calif began a PHP audit on July 30 under OpenAI's Patch the Planet program, and researcher Ryan Austin reported the first bug on August 11. OpenAI independently reported the same root cause the same day, and Wiz, using Wiz Atlas, Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, found and reported variants on August 24.
How much the models mattered is contested. OpenAI said frontier AI was key. Calif's own write-up says no special harness or non-public model was used in the initial discovery, and credits a theory about where PHP's old bugs hide. Chainguard's CEO told The Register his team independently found the same bugs on a Friday night with a basic prompt asking for bad vulnerabilities in PHP. The common thread is that finding this class of bug got much cheaper, and a months-long embargo now has to survive that.
How did the PHP2Shell embargo leak?
The coordinated release was set for October 22 at 14:00 UTC. According to the Foundation, on Tuesday October 20 around 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong score of 10.0. The Hacker News post that carried them reached 282 points. PHP published a pre-announcement at 19:30 UTC and moved the release forward a day.
Around 20:00 UTC Calif mistakenly published a video of its proof of concept, and copies circulated after it was deleted. On Wednesday at 07:41 UTC, more than six hours before the release, Chainguard published built images containing the fix. The Foundation says any attacker could study the fix in binary form while everyone else waited. A patch is also a diff, and attackers read diffs.
Chainguard's CEO says the company did not leak, that people were already being hit, and that it made the call to ship the fixes. The timeline itself is not in dispute.
Is PHP2Shell being exploited? What the sources say
- Amazon Threat Intelligence logged an exploitation attempt on a honeypot on October 17 and more attempts on October 21 from different infrastructure. It says it is unclear whether those attempts would have worked on real systems, and later said PHP2Shell is broadly exploited.
- watchTowr reported exploitation in the wild through its honeypot network. Cloudflare's CEO said it saw thousands of attempts in the ten hours before the announcement and millions by Thursday morning.
- CISA said it had not observed exploitation as of publication. The PHP team said it identified no functional exploit at release.
- watchTowr also says many exploit scripts flying around crash or do nothing. VulnCheck, as relayed by Tanium, found code execution works in some setups and that none of the public ones beat memory randomization on standard x86-64. Researcher Elias Taylor argues the bug is nowhere near as easy as Log4Shell, and still says patch.
An attempt is only a knock on the door. Amazon's advice is to investigate from at least October 17.
Which PHP versions get a PHP security update?
Fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For 7.4, 8.0 and 8.1 the PHP project published minimal source patches only. Older versions get nothing from the PHP project, and distributions may backport fixes, so ask your vendor. PHP 8.2 itself reaches end of life on December 31, 2026.
Governments did not wait. The NSA told organizations that could not patch to take PHP systems offline, and the UK's National Cyber Security Centre gave similar advice. The Guardian reports that Dutch sites including the national digital identity service, a Paris police site and several UK council sites went offline, and that Wikimedia took systems down as a precaution. Palo Alto Networks counted more than 22 million exposed instances.
What to do about PHP2Shell tonight
CISA's guidance is a good checklist: inventory every system that runs PHP, including copies inside other software, patch internet-facing systems first, and take PHP systems offline if you cannot update. Restart the workers after updating. Review logs back to October 17 for memory-limit errors and PHP workers launching shells.
This is the same lesson as the previous Daily Diff episode on eMudhra: a fix existing is not the same as the running process having it.
Two other stories from the same day
GitLab shipped critical patch releases, led by 19.5.1, on October 21. Its advisory describes an integer overflow in the regular expression compiler that could let an unauthenticated user execute arbitrary code on the GitLab server. It is CVE-2026-110264 with a CVSS 3.1 score of 10.0, affecting versions back to 7.0. GitLab.com is already patched; self-managed installations need the update.
In New Mexico, a judge ordered Meta to pay $25 billion in penalties in the state's Cambridge Analytica case, according to CNBC. The jury counted more than 43 million violations at up to $5,000 each, and the filing shows $219.5 billion awarded before it was reduced to $25 billion. Meta's chief legal officer said the company is confident it will prevail on appeal. It is a court order that Meta is appealing.
Verdict: SHIP IT
I would ship the PHP update tonight. The new version number is the only complete fix, the exploitation picture is disputed but real attempts exist, and the cost of an unneeded restart is small compared with a compromised server.
FAQ
Is PHP2Shell a zero-day?
Amazon logged an attempt four days before the fix, but the sources do not establish that any attempt succeeded. Call it a critical flaw with disputed exploitation.
Do WAF rules or config changes replace patching?
No. PHP, Amazon and the other vendors say updating is the only complete fix. Edge rules and settings such as limiting upload size reduce some paths.
What if I run an unsupported PHP version?
Ask your distribution for a backport, apply PHP's source patches for 7.4, 8.0 or 8.1 if you build from source, or plan a move to a supported version.
Sources
- The PHP Foundation: security release post-mortem
- GHSA-w8hw-w9fx-j79w
- GHSA-6wmf-4rv5-p3rp
- Wiz Research: PHP2Shell
- Amazon Threat Intelligence: MadPot
- CISA alert
- The Guardian, October 21
- SecurityWeek
- Tanium
- Elias Taylor
- The Register
- GitLab 19.5.1 release
- CNBC: Meta in New Mexico
This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.
