Short answer: PHP2Shell is the name for two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) that can let attackers run code on a server without logging in. AI-assisted researchers found them, PHP shipped fixes on October 21, and Amazon logged an exploit attempt on October 17. The fix is updating PHP itself, not your plugins.
On Saturday, October 17, a single exploit attempt hit one of Amazon’s honeypots, a decoy server built to attract attackers. It came through an anonymization network, and it targeted a bug that almost nobody outside a small circle of researchers was supposed to know about.
Four days later, everyone knew. Governments in Europe pulled websites offline. Japan’s prime minister told site owners to patch at once and to consider suspending sites that couldn’t. Cloudflare’s CEO talked about exploit attempts in the millions.
That’s the headline, and it’s fair on speed. On scale it needs fine print, and the fine print is where this story gets interesting. Below you’ll find the timeline, the bug in plain English, what AI really did, how much weight the “four days early” claim can bear, and what to do about it today. One early claim about a government breach has already been walked back, and we’ll get to that too.
What is PHP2Shell? (CVE-2026-109618 and CVE-2026-109619 explained)
PHP2Shell is the nickname for two vulnerabilities in the core of PHP. Both score 9.2 out of 10 (CVSS v4.0), and under the right conditions either one can let someone run code on your server without logging in. One also allows a Heartbleed-style leak of server memory, which can hold passwords, tokens and API keys (Wiz).
Think of a kitchen where a cook gets called away mid-recipe and leaves a half-prepped tray on the counter. The next cook assumes the tray is ready and serves whatever is on it. Now imagine a stranger who can pull the first cook away at exactly the wrong moment, then slip their own ingredients onto the tray. They get to decide what leaves the kitchen.
In PHP, “called away” means running out of memory. When a request hits the memory limit at the wrong moment, PHP can leave half-initialized internal data behind and trust it later. A following request handled by the same worker can then end up using stale or already-freed memory (PHP Foundation).
Two things make this worse than the average PHP bug. First, it happens while PHP is still reading the request, before your application code runs, so no login screen or in-app firewall gets a say. Second, it doesn’t depend on what you’ve built. Wiz showed code execution on fresh WordPress, Drupal and Joomla images, and said even a bare Hello World script on an affected version can be vulnerable. Calif confirmed it on 11 popular apps, including MediaWiki, Magento, phpMyAdmin, Nextcloud and Laravel (Calif).
It isn’t point-and-click, though. Datadog notes that an attacker has to size a request so an allocation fails at exactly the right moment, and also has to defeat ASLR, the memory-layout randomization that makes addresses hard to guess (Datadog). That may help explain why the first public proof-of-concept scripts mostly didn’t work.
Which PHP versions are affected, and which are fixed?
- Fixed: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Every earlier release on those branches is affected, according to watchTowr’s FAQ.
- Affected, with no official fix: PHP 8.1 and older, including PHP 7 and PHP 5. Wiz says the flaws reach back to PHP 5.4. PHP’s security team has shared source-only backports for some old branches, but those aren’t official releases, so ask your host or Linux distribution what they’re shipping. AWS’s security bulletin says no upstream fix exists for CVE-2026-109618 on end-of-life branches.
- Running out of time: PHP 8.2 loses security support on December 31, 2026.
- A third, narrower bug: On October 23 the PHP Foundation flagged CVE-2026-115560. It needs an unusual setup: an app that switches the session serializer at runtime before calling session_start(), with session upload progress still enabled. A fix is planned for the regular release cycle (The Hacker News).
The timeline: from a 2004 hunch to a Wednesday-morning scramble
- 2004: Researcher Stefan Esser publishes the first memory-limit remote vulnerability in PHP, the ancestor of this bug class.
- 2020: A bug report describes out-of-memory trouble with very long form variables. It doesn’t get much attention.
- 2024: An external audit (organized by OSTIF, carried out by Quarkslab and funded by Germany’s Sovereign Tech Agency) surfaces early signs of the memory problem. An exploit is theorized but no path is found, and competing fixes stall for months.
- July 30, 2026: Security firm Calif starts auditing PHP through OpenAI’s Patch the Planet program.
- August 1: Calif finds its first critical bug within days, having expected nothing that serious.
- August 11: Calif reports to PHP, and OpenAI independently reports the same root cause. PHP confirms Calif’s proof of concept on August 15.
- August 19–24: Wiz independently finds the flaws, confirms code execution on Drupal (Aug. 20) and WordPress (Aug. 21), and reports on August 24.
- September 18: OpenAI reports further attack vectors.
- October 17: Amazon’s honeypots log a PHP2Shell exploit attempt.
- October 20, around 15:00 UTC: The CVE IDs leak, with a wrong CVSS score (10.0) and a wrong release date. PHP pulls its release forward from October 22 to October 21. Around 20:00 UTC, the PHP Foundation says, Calif mistakenly posts a proof-of-concept video.
- October 21: Early-morning proofs of concept appear, Cloudflare reports early attacks at 07:43 UTC, and PHP ships fixes around 14:00 UTC.
- October 22–25: Attack attempts surge. On October 23 PHP flags a third, narrower flaw. On October 25 Unit 42 says it can’t confirm that a European government breach it had linked to PHP2Shell began with these CVEs.
Coordinated disclosure held for about two months. Then it cracked in the last 48 hours.
Is it really 70% of the web? The fine print
The 70% figure is real, but it answers a different question from the one most people hear. W3Techs found PHP on 70.5% of the websites whose server-side language it can detect (W3Techs). That counts sites using PHP. It doesn’t say how many run an unpatched, reachable version. Newsweek made the same point: PHP powering roughly 70% of sites doesn’t mean 70% of sites are vulnerable (Newsweek).
The exposed slice is smaller but still huge, and the estimates depend on who is counting:
- Palo Alto Networks counted more than 22.6 million exposed instances potentially vulnerable (Unit 42). That’s instances, not unique websites and not breaches.
- CybelAngel found about 2.24 million internet-facing hosts advertising PHP. Of the roughly 1.5 million that reveal a version, 59% run a branch that won’t get an official fix (CybelAngel).
- Bitsight counts nearly 37 million internet-facing systems running PHP or PHP-related software, which measures reach rather than risk (The Hacker News).
- Cisco Talos estimates that about half of PHP systems won’t get a patch (SecurityWeek).
These counts use different methods, so don’t add them up. Read them as a range, from millions to tens of millions, with a long tail of old PHP that nobody maintains. Ease of attack varies too. Apache with mod_php is the simplest target, since Calif showed code execution against arbitrary PHP scripts there under default settings. PHP-FPM setups, common with Nginx, need an application-specific path, though both Calif and the Foundation confirmed one exists.
Were attackers really knocking four days early?
Start with what Amazon actually reported, because the headline invites you to picture an army at the gate in mid-October. Amazon Threat Intelligence says its MadPot honeypot network logged one exploitation attempt on October 17, from an IP address linked to a commercial anonymization network. AWS reasons that a hit like that, from masked infrastructure and during an embargo, points to a threat actor. It also says it doesn’t know how that actor learned about the bug, and that it can’t yet say whether the attempts it saw would have worked against real systems (AWS Security Blog).
So how did anyone know? Nobody has said. A leak is possible. So is independent discovery: Calif, Wiz and OpenAI all landed on these bugs within weeks of each other, so a fourth party getting there isn’t far-fetched. That’s an inference, not evidence.
October 21, hour by hour:
- About 02:00 UTC: Amazon sees the first of several proof-of-concept exploits, roughly twelve hours before the planned release.
- 07:41 UTC: The PHP Foundation says Chainguard published built images containing the fix, which let anyone study the patch in binary form. Chainguard’s side of the story wasn’t in the sources reviewed for this article.
- 07:43 UTC: Cloudflare says it’s seeing early attacks. Hadrian reports exploitation at scale by 11:35 UTC.
- After the patch: Cloudflare’s CEO says millions of attempts hit its network by that evening (Fortune). Cloudflare sells the firewall protection it describes, and those traffic figures haven’t been independently verified.
What hasn’t been shown is successful attacks at scale. watchTowr says none of the proof-of-concept code circulating publicly achieves code execution (SecurityWeek). Sophos blocked a payload tied to a Mirai-derived botnet before it was delivered, and VulnCheck saw at least one failed attempt to plant a web shell. Beazley Security wrote on October 23 that it knew of no confirmed mass exploitation (Beazley). CISA said it hadn’t observed exploitation when it published its alert. On October 22 watchTowr noted that neither CVE was in CISA’s Known Exploited Vulnerabilities catalog, and a check by Brandefense found the same on October 25 (Brandefense). One startup founder claimed on X that attackers stole their source code. Fortune reported the claim, and it remains unconfirmed.
Then came a walk-back. Unit 42 first reported a compromise at a European government agency that showed signs of AI-driven post-exploitation, such as command output formatted for a model to parse, and linked it to PHP2Shell. On October 25 it updated its brief to say it can’t confirm that the initial access involved these CVEs (Unit 42). Separately, security firm CYFIRMA says it found a suspected North Korea–linked group using PHP2Shell to probe 216 hosts from compromised nodes, an attribution it makes with moderate confidence (The Hacker News). Treat both as developing.
The verdict: At least one actor was probing four days early, and large-scale scanning began hours before the patch. “Attackers were knocking” is fair. “Attackers were already inside millions of sites” isn’t supported by anything public so far. Amazon’s practical advice is the part to act on: start any investigation from October 17, not from disclosure day.
What did AI actually do?
The tidy story is “AI found a bug humans missed.” The real one has more people in it.
Calif researcher Ryan Austin started with a hunch. He knew PHP’s history and suspected relatives of Esser’s 2004 bug were still around. He asked an LLM to help find ways to exceed PHP’s memory limit on demand, then to review how PHP behaves when it’s interrupted. The agent flagged an ordering problem in how PHP updates its internal hash tables. Austin had the model turn that finding into a reusable pattern file, and the pattern then surfaced the session upload-progress bug. Calif says its initial discovery used no special harness and no models that weren’t publicly available.
Earlier AI passes hadn’t found these bugs. Calif says everyone and every lab had already run extensive AI-assisted audits of PHP, and the PHP Foundation says it scanned PHP earlier this year with Anthropic’s Claude Mythos through Alpha-Omega before adding other tools. Calif’s explanation for what changed is direction. In its write-up, models tend to work from recent, prominent bugs toward nearby code and don’t reliably start from obscure twenty-year-old exploitation tricks, so a researcher who remembers the history can steer them there.
On the exploit side, Wiz worked independently with Gemini 4 Argon, GPT-5.6 Sol and its own Atlas tool. It says AI let it adapt working exploits across applications in hours, and it claims one researcher did in a week what once took a world-class team months. That’s a vendor claim, though it matches Calif’s account.
A word on incentives. Wiz sells security software and is owned by Google, whose model it credits. OpenAI sells AI models. Cloudflare sells a firewall. None of that makes them wrong. It’s a reason to read their numbers with one eyebrow raised.
The human bottleneck: how a 2024 warning sat for two years
The PHP Foundation’s own post-mortem is blunt. After the 2024 audit, its team developed several competing fixes, and each had a cost: broken backward compatibility, new denial-of-service risk, or changes to many third-party extensions. Working by consensus and afraid of picking wrong, the security team let work on a fix “stall and restart repeatedly over months.” The Foundation calls it a structural failure rooted in its decision process and a lack of resources.
Since then it has created an Ecosystem Security Team and is moving security decisions from consensus to majority vote. It says it has published 15 CVEs since July 1 while working through more than 100 reports that were invalid, duplicates or not reproducible. It also warns that tools now find bugs faster than people can decide how to fix them, and it asks the companies, hosts and governments that depend on PHP to fund it.
This is the part the “AI saves the day” story skips. The bottleneck wasn’t finding the weakness. It was turning a theoretical risk into a decision, a patch and a release across an enormous ecosystem, and that bottleneck is about to get busier.
Why this is bigger than PHP: the window is shrinking
PHP2Shell fits a pattern that predates it, though the data aren’t uniform.
- Mandiant estimates that mean time to exploit fell to about minus seven days in 2025, which means that on average exploitation starts before a fix is public (Google Cloud).
- VulnCheck found that 28.96% of newly exploited vulnerabilities in 2025 were exploited on or before the day their CVE was published, up from 23.6% in 2024 (VulnCheck). Its first-half-2026 figure was lower, at 23.43%, and it describes early exploitation as holding steady rather than accelerating (VulnCheck, 1H 2026).
- AWS’s read on PHP2Shell is that more actors can now act within hours of technical details emerging, because AI-assisted analysis makes it cheaper to turn a patch or advisory into a working exploit.
These figures measure different things, so treat them as separate lenses on one problem rather than a single trend line. The shared message is that patch cycles measured in days or weeks are being tested against an adversary who thinks in hours.
OpenAI frames PHP2Shell as a Defender’s Window. To its knowledge, frontier AI found these bugs before attackers did, which gave maintainers time to prepare. It has committed $1 billion in subsidized access to its security tooling for under-resourced defenders, and it says it expects similar findings to increase sharply in the coming months (OpenAI).
Both readings can be true. The window was real: researchers had about two months, and Cloudflare, AWS and others shipped protections before disclosure. The window also leaked. An embargo is a head start, not a shield, and it protects defenders only until someone else finds the same bug or gets a hint of it.
What to do right now
If you own a website (the no-jargon version)
- Find your PHP version. In WordPress, go to Tools → Site Health → Info → Server, or ask your host. The version you see on the command line can differ from the one serving your site.
- Update PHP to a fixed version: 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or your host’s equivalent patched package.
- Don’t stop at plugins. Updating WordPress or plugins won’t fix a PHP-level flaw.
- If you’re on PHP 8.1 or older, move to a supported version. Ask your host or distribution whether they ship a backport, because upstream there’s no official release.
- Plan for PHP 8.2’s end of life on December 31, 2026.
If you run servers or manage a team
- Inventory everything with PHP in it, including Docker base images, appliances, admin panels and vendor products that bundle PHP.
- Patch in hours, not weeks, for internet-facing systems. AWS’s advice is to measure patch timelines for critical internet-facing flaws in hours.
- Hunt back to October 17. ReliaQuest’s lab reproduction found a telltale sequence: a POST that returns a 500 error, PHP logging memory exhaustion and heap corruption, and the Apache worker handling the request crashing (ReliaQuest). Also look for POSTs containing PHP_SESSION_UPLOAD_PROGRESS, oversized or malformed PHPSESSID cookies, unexplained PHP worker churn, and unexpected shell processes spawned by PHP workers.
- If you suspect compromise, rotate secrets the server could have held in memory, such as passwords, tokens and API keys. That’s general good practice, not an official PHP step.
- Treat a WAF as a stopgap only. Cloudflare’s rules help only if your server accepts traffic exclusively through Cloudflare.
- Add behavior-based detection, because first exploitation often arrives before signatures exist.
If you depend on open source
The PHP Foundation’s ask is simple: sponsor the people who maintain what you rely on.
The bottom line
PHP2Shell is a fix-it-now story and a warning shot. The bug class is old, the discovery was a human-and-machine partnership, the embargo cracked, and at least one actor was probing while defenders were still wrapping up. The scary part isn’t one language or one weekend. It’s that the gap between “someone found it” and “someone is using it” is now measured in hours.
Check your PHP version today. It takes two minutes, and it’s the cheapest security task you’ll do this year
