59% of PHP Servers Get No Official Fix. AI Just Made Them Worth Hacking.

PHP2Shell sat in the engine for a decade. Frontier models turned it into a working exploit in days, and older bugs are next.

8 min read

Damn. The first attacks hit at 07:43 UTC on October 21, about 6 hours before PHP shipped the fix, according to the Sansec forensics team. Dutch government sites pulled themselves offline as a precaution. Gaming and forum services went dark or into maintenance, from Granblue Fantasy to parts of 4chan, according to an outage list posted during the incident. The FBI's cyber division told anyone who couldn't patch right away to take the system down. The exploit was running before the fix even existed.

What makes this bug different from your usual WordPress hole is where it lives. It sits inside the PHP engine itself, and it fires while the server is still reading the request, before the first line of your own code runs. No plugin update, no theme update, no CMS update protects you. One researcher, Ryan Austin at Calif, demonstrated unauthenticated remote code execution (RCE) on 11 applications, from WordPress to Magento.

And the real story is older than any of that. This bug was nothing new. It had been sitting on PHP's desk for years, cataloged, known, judged too expensive to exploit for anyone to worry about. Until this summer. The question I keep turning over is this: if AI drops the cost of exploitation for everyone, does the defense gain as much as the attack?

The wells were mapped years ago. The models made them worth pumping.
The wells were mapped years ago. The models made them worth pumping.

The Bug Was Already on File

The lineage is long. According to Calif's writeup, a memory bug like this first surfaced in 2004, courtesy of Stefan Esser, got logged again as issue #78876 in 2020 with no real follow-up, and turned up a third time during a 2024 security audit run by OSTIF and Quarkslab.

The PHP Foundation confirms an exploit was theorized back in 2024, but nobody had a concrete attack path, so the fix stalled for months. Every option carried a cost: break backward compatibility, open a new denial-of-service risk, or force third-party extensions to rewrite their code. The Foundation is also honest that other issues with clearer impact crowded this one out that year. A small team with limited hands plays as big a role here as any cold risk calculation.

Wiz, the cloud security firm Google acquired, explains why the bug stayed out of reach for so long: pulling it off meant chaining several bugs together and rewriting the exploit for each target's memory layout, right at the edge of what human researchers could manage.

One does not simply hand-write a working exploit for every server's memory layout.

That difficulty was doing a job nobody had assigned it. It worked as a security barrier, an unofficial one, propped up entirely by how expensive the bug was to weaponize.

A vulnerability isn't dangerous until someone can afford it.

What Changed in August

Then, in a single month, three teams found it independently. Call it an accidental speedrun of a bug that had sat untouched for years.

Calif got there first. On August 1, working inside OpenAI's Patch the Planet program, Ryan Austin surfaced several remote-code-execution paths using GPT-5.6 Sol. OpenAI flagged the same root cause on August 11, the same day Calif reported it, according to the PHP Foundation. Wiz landed third, reporting on August 24 after a discovery on August 19, using its own Wiz Atlas tooling alongside Gemini 4 Argon and GPT-5.6 Sol.

Wiz's claim is the loud one: the models let a single researcher adapt working exploits to several applications in hours, and do in a week what a world-class team would need months to finish. Worth naming the interests in the room. Wiz is owned by Google and quotes Gemini's own security lead. OpenAI sells a security product called Daybreak and shipped a Codex version-checker skill the same day the patch dropped. Both companies have a model to sell and a reason to make it the hero.

Calif's account cuts the other way, and it is the more interesting one. Austin writes that he used no special harness and no private model, nothing a reader couldn't rent. What made the difference was his own knowledge of PHP's vulnerability history, which pointed the model at old primitives it would never have explored on its own. The AI didn't replace the expert. It took the expert's hunch, the one that used to be too expensive to chase all the way down, and made it cheap to follow.

One detail to handle carefully: the PHP Foundation mentions an earlier scan this year using Claude Mythos, run through the Alpha-Omega project, without saying what it did or didn't find. So this isn't a story about one model catching what another missed. No source says that.

Three teams found it in 3 weeks with models anyone can rent. The question that lingers is who got there first and never said a word.

Oil at $100 Makes Shale Profitable

The wells were mapped years ago. The models made them worth pumping.
The wells were mapped years ago. The models made them worth pumping.

This is where PHP stops being the story.

When the price of oil climbs, fields that were mapped years ago and left alone suddenly become worth drilling. Nobody discovered a new well. The math under the old ones just changed.

Vulnerabilities behave the same way. A bug is only dangerous in practice when exploiting it costs less than what it yields. PHP's memory bug was a mapped field, surveyed in 2024, capped and abandoned because the extraction cost was absurd. Frontier models dropped that cost. And the moment they did, every bug filed under "theoretical" or "too complex to bother" quietly changed value, in PHP and in every other codebase written by people who were counting on difficulty to keep them safe.

OpenAI says as much in its own writeup: it expects this kind of discovery to climb sharply over the coming months. The same thing already happened in miniature earlier this year, when one CLI command surfacing bugs that sat for months briefly knocked billions off cybersecurity stocks.

The wells were mapped years ago. The models made them worth pumping.

883,717 Servers With No Fix Coming

So how big is the first field?

As of October 21, the day the patch shipped, CybelAngel counted about 2.24 million internet-facing hosts announcing PHP. CybelAngel sells attack-surface monitoring, and it's leaning on Shodan data published a day earlier by a researcher who goes by Mallory, so treat the exact figures as a snapshot, not gospel. Of the hosts that reveal a version, 59% (883,717 of roughly 1.5 million) run on a branch that will get no official fix, because PHP only patches the 8.2 through 8.5 lines. PHP 5.x alone accounts for 368,570 hosts. In France, 25,439 hosts sit on versions with nothing coming. On the WordPress side, 35.1% of sites run a PHP version the project no longer patches.

A few caveats ride along with those numbers, and they cut both ways. The counts are hosts, not sites or organizations, so one number can hide many sites or several servers behind a single business. Around 740,000 hosts hide their version entirely, which means the real exposure is probably higher than it looks. But some Linux distributions, Debian, Ubuntu, Red Hat, backport security fixes into old versions, which means some of those "unpatched" hosts are actually fine. Exploitability depends on the setup, too: servers running PHP baked straight into Apache (mod_php) are the most exposed.

Now the part that stings if you run a site. Your WordPress install can be fully updated, every plugin current, every theme patched, and still be sitting on a vulnerable PHP, because the runtime belongs to your host, not to you. On shared hosting there's exactly one move available: ask your host whether they've applied the fix, and keep asking until you get a straight answer. Huntress, for its part, said it hadn't seen exploitation against its own customers by late morning on the 21st, which doesn't settle much this early either way.

You can patch everything you own and still get owned by what you rent.

The cleanest version of that advice is structural: a site with no PHP had nothing to patch the morning the exploit started landing.

Defenders found this bug before attackers did. So why were servers getting hit 6 hours before the fix shipped?

Machine-Speed Discovery, Human-Speed Fixes

The answer is that finding and fixing run on different clocks.

What we know: vulnerability discovery just went symmetric. For once the defenders got there first, which is the core of what OpenAI calls the "defender's window," and the cost of finding the next bug is falling for attackers and researchers alike.

What we still don't: the fix chain is stubbornly human. The PHP Foundation calls its own months-long delay a structural failure, admits it shipped 15 CVEs (the public tracking IDs for vulnerabilities) since July 1, and says it triaged more than 100 reports that turned out to be invalid, duplicated, or impossible to reproduce. A person decides every single fix, weighing tradeoffs a model can surface but can't choose between.

And the coordination held right up until it didn't. 2 days before the planned release, the CVE identifiers leaked with a wrong CVSS severity score of 10, the maximum. A proof-of-concept (PoC) video went out by mistake from Calif. Then Chainguard broke the embargo at 07:41 UTC by publishing container images that already contained the fix, according to the PHP Foundation. The first attacks showed up 2 minutes later, though no source draws a line between the two, and it's too early to draw one.

The machine finds at machine speed. The fix moves at the speed of a human reading a bug report, weighing options that all break something, then pushing a patch out to a fleet where more than half the servers will never receive it. Whether the fixing side can ever catch up to the finding side is still an open question.

That memory bug was a mapped field, surveyed and left in the ground because drilling it cost too much. The models changed the price. The next field is already down there, in some other language, waiting for the same thing to happen.

Sources

A PHP bug can sit unfixed for years, then AI makes it exploitable in hours. The demo-vs-product checklist in the welcome kit lays out 8 concrete criteria for systems that can recover from incidents like this instead of just going dark.

→ Get the welcome kit

This post may contain affiliate links. If you click them, I might earn a small commission — costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.