PHP2Shell

PHP2Shell is the collective name for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Under certain conditions, they made it possible to execute code on a server without logging in; PHP installations that serve web requests are affected, and the risk is highest for Apache with the mod_php module. Both received a score of 9.2 on the CVSS 4.0 scale. PHP runs on 69.2% of websites whose server-side language is known.¹²³

According to the PHP Foundation, the first signs of one of the bugs were found back in 2024, but the fix got stuck. In 2026 the vulnerabilities were found independently, with the help of AI, by Calif under the OpenAI Patch the Planet program, by OpenAI itself and by Wiz. Leaks derailed the coordinated release of the fixes, and the first attack attempt, according to Amazon, came four days before disclosure. As of 25 October there are no confirmed breaches; of the services that remain vulnerable, most run on PHP versions for which there is no official fix.¹⁴⁵⁶

History

• 2024Quarkslab carries out the first external security audit of PHP in years; the PHP Foundation obtained the funding for it from the Sovereign Tech Agency. While fixing one of the findings, a PHP developer sees the first signs of an out-of-memory problem that will later become CVE-2026-109618. The fix stalls for months.¹ ¶ cjbjq4na9
• 22.06.2026OpenAI announces the Patch the Planet program: together with Trail of Bits, it will help open-source maintainers find and fix vulnerabilities.⁷ ¶ cj65i2dcj
• 11.08.2026Calif, which has been testing PHP under Patch the Planet since 30 July, reports the first vulnerability to the PHP security team. From this day on, the fix is the top priority for the PHP Foundation’s team. OpenAI independently reported the same root cause, and on 18 September it reported new attack vectors.¹⁸ ¶ c9buuy92f
• 24.08.2026Wiz reports its findings to PHP. It found the first one on 19 August with its Wiz Atlas tool and the Gemini 4 Argon and GPT-5.6 Sol models, and it confirmed unauthenticated code execution on Drupal and WordPress.⁹ ¶ cwp6k86n2
• 20.10.2026The CVE numbers leak online two days before the planned release; Calif mistakenly publishes a video of a working exploit. The release is moved one day earlier.¹ ¶ c8mhxyghn
• 21.10.2026PHP releases versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 8.1, 8.0 and 7.4 the team publishes only minimal fixes in source code; there are no official releases for them.¹² ¶ cgydsfait
• 23.10.2026PHP reports a third vulnerability of the same kind, CVE-2026-115560: it also affects the updated versions, but only with an unusual configuration, so the fix will ship in the regular release cycle.² ¶ cq5qrgrfb

Data

Who is left without a fix. Every day Censys counts internet-facing services running PHP, by the version they report about themselves. The unit is a service, not a server or a website: different companies’ counts differ by a factor of tens, so only rows of the same table can be compared. Not every service reports its version: as of 25 October the version is unknown for 56.9 million of the 99.6 million PHP services found, and that number grew from 16 million over the week because Censys was finding more services. The figures in the table are therefore a lower bound.⁶

¶ cuc8axysj

On 22 and 23 October the number of updated services grew by more than 4 million a day; on 24 October, by less than 1 million. The most common version of all is 7.4.33, from a branch with no official fix: 6.7 million services. Censys counts all old branches as vulnerable with no fix, but about 3.1 million of the 23.5 million are versions older than 5.4, and Wiz writes that versions from 5.4 onward are vulnerable.⁹⁶ ¶ c3cpdbjvf

[EDITORIAL CONCLUSION] Updating moves fast wherever someone is there to do it, and stalls almost at once: by the morning of 25 October, about 9 million services on supported versions were still without the fix, and about 20 million on old vulnerable versions for which there is no fix at all. The number of the latter did not go down over those days. ¶ c968v4bz6

Incidents

Leaks before the release, October 2026 ¶ c7xzna2w2

The release was scheduled for 22 October at 14:00 UTC. On 20 October at around 15:00 the CVE numbers appeared on forums and social media, with the wrong release time and a wrong score of 10.0. The leak contained no technical details. At 19:30 PHP published a pre-announcement and moved the release one day earlier: distributions were still building packages, and releasing at once would have left many people without an easy way to update.¹

After the leak and the pre-announcement, Calif mistakenly published a video in which its exploit worked against several targets. The video was taken down, but copies spread across social media; according to the PHP Foundation, it sped up the appearance of proof-of-concept exploits. The mitigation advice that PHP began sending to a few critical infrastructure operators at around 23:00 may also have leaked, the foundation says.¹

According to the foundation, on 21 October at 07:41, more than six hours before the release, Chainguard posted built images containing the fix. According to the foundation, Chainguard “unilaterally broke the embargo”, and any attacker could study the fix while all other PHP users were still waiting for it. Chainguard’s head, Dan Lorenc, explained the decision by saying that exploits had already appeared online.¹¹⁰¹¹

Attacks before and after disclosure, October 2026 ¶ cnch37ut9

According to Amazon, the first exploitation attempt hit its MadPot honeypot network on 17 October, four days before disclosure, from an address belonging to a commercial anonymization network. On the morning of 21 October, still before the release, the attempts multiplied and came from different addresses. Amazon does not know whether any of them would have succeeded against a real server.⁴ ¶ cntwbn33n

Cloudflare turned on default protection for customers with its free and paid web application firewall at 03:02 on 21 October, before disclosure. According to its CEO, Matthew Prince, the company saw thousands of attack attempts in the 10 hours before disclosure, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and then the count went into the millions.¹²¹³ ¶ c5tfj6mar

Among the attackers is a botnet: Sophos intercepted an attempt to install Potassium, which it believes is a variant of Mirai.¹⁴ ¶ ca3cc2shq

There are no confirmed breaches. CISA had not seen successful exploitation as of the publication of its alert. On 22 October Sophos reported one successful breach, but corrected itself that same evening: there is no evidence of a successful compromise. SOCRadar found an attack kit on an attackers’ server, along with traces of checks on about 20 websites: none of them met the conditions for the attack.⁵¹⁵¹⁶ ¶ ckj7jbydd

Criticism

A failure within. The PHP Foundation says outright that “the delay was a structural failure”, caused by how the security team made decisions and by a shortage of people.¹ ¶ cjjeciweq

Success despite the leaks. Johannes Ullrich of the SANS Internet Storm Center believes that coordinated disclosure on the whole worked and delivered tested fixes on time, and that leaks from “some vendor(s) not playing by the rules” should not overshadow that.¹⁷ ¶ cz5h4dfrp

AI slop instead of exploits. There turned out to be many published “exploits” and almost no working ones. Bojan Zdrnja of SANS found among them “an unbelievable amount of AI generated - erm, slop”; VulnCheck found hundreds of repositories on GitHub, of which only a handful are genuine; members of hacker forums, according to a review by Flare, call the public code “AI slop” and “vibe coded”. Ullrich wrote on 23 October that, as far as he knew, there was no reliable public exploit, but several companies had stated that they had working code.^17181920 ¶ c8jkkhna6

Embargo versus AI. Amazon concludes that an embargo protects only until someone else finds the same bug: AI makes it cheaper to turn a fix or an advisory into a working exploit, and an investigation should start from the first known attack, not from the disclosure date. Wiz writes that a single researcher with frontier models did in a week what would previously have taken a world-class team months.⁹⁴ ¶ ctq7enzyg

Development

The PHP Foundation is changing how security is organized. In the security team, decisions will be made by majority rather than by consensus; the foundation’s leadership will learn about a serious vulnerability much sooner. An ecosystem security team has been working since May 2026, the foundation has an AI security engineer, and in July and September it was joined by staff for triaging reports and hardening the code. The workload has grown because of the same AI tools: since 1 July the team has published 15 CVEs and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. The foundation is asking companies, hosting providers and governments for funding.¹ ¶ cqruv52g4

CISA advises those who cannot update, or who run PHP 8.1 or older, to take PHP-based systems offline until they are updated.⁵ ¶ csvzak3wc

[EDITORIAL CONCLUSION] In PHP2Shell, three independent teams used AI to find critical vulnerabilities in one of the major open-source projects over the course of August. The main conclusion follows from this: a secret no longer holds. If several teams find the same bug this quickly, a 71-day embargo holds only as long as nobody else has found it yet, and, according to Amazon, the first attack came before disclosure. The weak point is now not finding but people and money for fixing, and old versions that nobody will update. More on the phenomenon in the article “AI vulnerability discovery”. ¶ cmw3tbywx