Public evidence for PHP2Shell has turned out to be far thinner than its headlines. It’s a bad bug, yes, but who caused so much attention to it instead of other bugs?
Wiz frames the reach of the flaw as 70% of the internet, and its write-up says the impact “cannot be overstated.” OpenAI called it one of the most impactful security issues in recent memory, a line that Fortune carried.
This is a pattern. In 2023 I noted Wiz’s Microsoft AI leak report was technically sound and overstated the risk to sell the product. OpenAI has become synonymous with overstatement and bellicose self-promotion. Weren’t they recently warning us the world already would be ended?
Attempts at compromise, versus actual compromises, are separate numbers. No vendor has published a confirmed compromise, and the exploit experts I have spoken to have seen none. TechTarget reports Cloudflare seeing attempts in the thousands to millions, and Amazon honeypots logging probes from 17 October. Recorded Future says the public evidence leaves the full extent of successful exploitation and confirmed compromises open.
The public proof-of-concept code is weaker.
SC World quotes a developer who tested the three most-starred GitHub repositories against a vanilla PHP server. Once again proving, as an aside, that stars are a worthless measure. Each “starred” code failed to reach code execution. Chainguard’s CEO told TechTarget that many of the public exploits were fake or were removed before they worked. Recorded Future adds that the author of the bundle later invalidated his own theory.
The leaked bundle that set off the panic was, in Kevin Beaumont’s reading, machine-generated and only half right, and the copies on GitHub that built on it inherited those mistakes.
The advisories explain part of this. Both CVE-2026-109618 and CVE-2026-109619 rate attack complexity as high (AC:H). Calif’s write-up shows why. The chain needs control over memory layout and, on PHP-FPM, cooperation from the application.
Compare that with a bug I reported to Qdrant that was just disclosed this week.
GHSA-frc7-44gm-99qq carries a CVSS score of 9.8, with attack complexity low, no privileges required, and no memory tricks. I reported it to the vendor in February and then again formally through the German BSI on 9 July, and it was published on 22 October.
I should point out PHP’s advisories use CVSS v4.0 and Qdrant used the old v3.1, which means the comparison depends on an attack complexity field. I mean, aside from the fact that the Swastikas run on Qdrant and the whole world runs on PHP.
Patch history
The history of patching is always a great story.
In January 2003, Slammer was a single UDP packet carrying 376 bytes against a Microsoft SQL Server bug patched six months earlier (MS02-039, 24 July 2002). It reached 90% of vulnerable hosts in ten minutes, doubling every 8.5 seconds. There were no funny memory tricks and no second request. The attack complexity was zero, so the whole story was six months of customers left vulnerable by (failing to patch from) the richest company in the world.
In May 2017, WannaCry ran on a Windows bug patched two months earlier (MS17-010, 14 March 2017) and shut down hospitals and factories that had not applied it. In June 2017, NotPetya ran on the same patched bug. That same spring, Equifax was breached through an Apache Struts bug whose fix (S2-045) had shipped in March; GAO put the exposure at least 145.5 million people.
In December 2021, Log4Shell was one line in a text field. The fix shipped in days, and the Cyber Safety Review Board called it an endemic vulnerability whose instances “will remain in systems for many years to come, perhaps a decade or longer.”
Every one of these had the kind of easy exploit that almost anyone could run. PHP2Shell does not rise to this level, yet. That is the difference between a bad week and a bad year, and so far PHP is getting a lot more attention than if AI hadn’t tried to convince everyone it was the only bug in town.
PHP history
PHP has been here twice before, three times if you know the secret.
In May 2012, CVE-2012-1823 leaked by accident from PHP’s own bug tracker. The rushed fix was broken within hours and the second fix followed a week later. Scanners still probe for it. In June 2024, CVE-2024-4577 was patched on a Thursday and in ransomware by the weekend. Both were argument-injection bugs, one request, again no memory layout to manage.
The secret is the lineage Calif lays out. Stefan Esser found the first PHP memory_limit remote bug in 2004 and withheld his exploit. In 2020 a report of long multipart variables causing out-of-memory conditions sat in the tracker as a minor bug. In 2024 an OSTIF and Quarkslab audit found a related issue, could not prove exploitation, and it went unfixed.
And so a very old bug was turned it into code execution in August 2026 with an AI assistant and a history that said where to look.
Twenty-two years from first sighting to patch. The hard part was never finding the bug. It was proving there is an exploit, and then getting one to work, which is where everyone except the discoverers still sits today.
Patching now
Patching is the gap that’s easy to measure. Censys counts 3,082,629 hosts and 56.7 million web properties running PHP. Its dashboard at php2shell.censys.com updates hourly. In the latest update, PHP 7.4, 8.0 and 8.1 received source-only backports with no compiled release. The older branches stand as follows.
| PHP branch | Patch status |
| 7.4, 8.0, 8.1 | Source-only backports, no compiled release |
| 5.4 through 7.3 | Nothing |
Given all that, if you ask me, the risk is low. The potential is high, higher than before AI made a big deal about it, still not as high as other bugs getting no attention at all.