For twenty years, writing a working exploit for a memory bug was something only a handful of people in the world could do. Last Wednesday that stopped being true. Two vulnerabilities in the PHP core sat in the code for over ten years, because someone had found them, but nobody could turn them into a usable attack. Then a language model came along and chained them together in a week. And now the finished script is circulating on the internet. It can pull data out of practically anything. Including your data.
On Wednesday, October 21, 2026, the PHP project released emergency security fixes for two critical vulnerabilities in the language interpreter itself, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 and let an unauthenticated attacker run arbitrary code on a web server. Together they are called php2shell. According to W3Techs, PHP powers roughly 70 percent of websites, so this affects nearly everyone who runs anything more complicated than a static page.
That alone would be big news, but not new news of its kind. Critical holes in PHP turn up regularly. What’s new is something else: how these bugs got their exploit. The means of abusing them.
A latent bug for ten years
Both vulnerabilities are memory-handling bugs. Put simply: when PHP hits a fatal error while processing a request, typically running out of memory, it can’t safely clean up after itself. CVE-2026-109618 leaves internal data only partially initialized, and the subsequent cleanup works with it as if it were fine. CVE-2026-109619 leaves dangling references to memory that has already been freed, and the next request on the same process can latch onto them. In jargon, it’s a use-after-free and a type confusion in OPcache.
These bug patterns have been present in PHP for years, in some versions for over a decade, going back to PHP 5.4. So why did nobody exploit them earlier? Because the mere existence of a memory bug is half the work. The other half, the harder one, is turning it into a reliable attack. That means chaining several bugs together, understanding how a specific PHP version lays out and recycles memory, and tuning the whole thing for each target separately. A different version, a different configuration, different application behavior, and the assumptions the attack rests on collapse.
Historically this was the domain of a few dozen specialists in the world. Months of work, at the edge of what a human researcher can practically manage.
What the AI did
Artificial intelligence found the bugs and built the exploit, and two teams did it independently.
The security firm Calif (led by Thai Duong, with the finding credited to Ryan Austin) went through the PHP code with OpenAI’s GPT-5.6 Sol model as part of an initiative OpenAI named Patch the Planet. They reported the first hole to the PHP developers as early as August 11. The second firm, Wiz (acquired by Google last year), arrived at the same bugs on its own, using its own multi-agent system Wiz Atlas, supplemented by the Gemini 4 Argon model and, again, GPT-5.6 Sol.
Wiz summed it up in a sentence worth pausing on: one researcher did in a week the work that a top team would previously have needed months for. According to them, the models handled exactly the tedious, time-consuming part: adapting the attack to different versions and memory layouts through repeated testing and debugging. That’s why Wiz compares php2shell to Heartbleed from 2014 and speaks of a turning point.
I don’t want to paint it as magic, though. Calif itself adds a sober note that most of the excited headlines left out: no model can simply fish out “all the bugs” with a single prompt. A human is still there, steering the research, asking questions, verifying. AI didn’t replace the expert, it sped them up. But in security, speed-up is itself a change in the category of danger.
Where the bar has really dropped
Now to the claim that “today any IT enthusiast can replicate this.” It’s true, but only partly, and it’s worth distinguishing where it holds and where it doesn’t.
Writing such an exploit from scratch still isn’t something just anyone can do. What Calif and Wiz demonstrated required top people with models and tooling. But two other things have changed fundamentally.
First: the first working exploit exists at all. Previously these bugs stayed theoretical, because nobody found it worthwhile to invest months of work into an uncertain result. AI flipped that equation. A vulnerability that was “impractical” is suddenly within reach.
Second, and this is the dangerous one for the masses: once the finished php2shell script leaked, adapting it to a specific target is exactly the task AI does best. Have a server running PHP 8.3 in some particular configuration? You take the public script, feed it to a model, and let it tune it to your environment. This really can be done by almost anyone now. Not because they understand use-after-free, but because they don’t have to.
And that’s exactly how it played out. The whole coordinated process, which was supposed to buy defenders time, collapsed when someone dumped the details on Hacker News on October 20, before the fixes were released. The firm Sansec expected mass exploitation within fifteen minutes of the patch release. watchTowr, Aikido and Patchstack all reported the first attacks in real-world traffic within a few hours.
How the security industry is reacting
The reaction was unusually fast and in itself shows where things are heading.
Cloudflare deployed protection rules in its WAF (web application firewall, a filter in front of the web server) at 03:02 UTC, roughly nine hours before the official disclosure, even for customers on the free plan. Because of this bug it even launched a new capability it calls full transaction detection: it inspects not only the incoming request but also the server’s response, to tell whether the attack succeeded. That’s technically interesting and practically useful.
There is a catch, though, actually several, and it’s fair to name them. All the numbers about attacks come from Cloudflare, which sells that protection, and it hasn’t published any concrete figures. For paid plans it itself asks customers to verify that the rules are running in blocking mode, which suggests that for some they aren’t. And above all: a server reachable directly via its IP address, outside Cloudflare, receives requests that never pass through that filter at all. A WAF is a second layer of defense, not a fix. The only real fix is updating PHP on the server.
OpenAI released the Patch the Planet initiative along with a tool on GitHub, php2shell-checker, with which you can verify whether you’re running a vulnerable version. More interesting is the framing they added: they talk about a “Defender’s Window,” a period when frontier AI finds a bug before attackers do and gives defenders a head start. It’s a nice idea. It’s just that with php2shell, one leak on a forum closed that window before it could serve its purpose.
Government agencies chimed in too, the American CISA, the NSA and the European CERT-EU, with urgent calls for immediate updates. That’s routine. What comes next is not routine.
And the whole thing ended unpleasantly anyway. Months of quiet, coordinated work were supposed to culminate in a moment when the patch ships and only then does the world learn the details. Instead, someone dumped the bug identifiers on Hacker News on October 20, watchTowr confirmed within hours that they were real, and PHP had to move up the release by a day and ended up making it even sooner. The head start that OpenAI called the “Defender’s Window” closed faster than it was supposed to. Defenders got hours where they’d counted on days.
What will have to change
A few things follow from this event that I think will hold beyond a single hole in PHP.
The patching window has shrunk to minutes. As long as building an exploit took months, defenders had slack. When AI delivers it in a week and the adaptation in hours, the old advice applies doubly: defense-in-depth, meaning multiple layers of protection, stops being a luxury. Anyone relying on “it’s been fine so far” will lose.
A runtime written in C is a ticking source of these bugs. PHP, and not just PHP, stands on foundations where a memory bug means running someone else’s code. A decade-old latent hole in the core shows that rewriting in safer languages or adding stronger runtime guarantees won’t be an academic exercise. It will be a necessity, once models have gone through the rest of that codebase.
This was the first case, not the last. Today only two research teams had top-tier models. In a year, twenty defensive firms will have them, and so will twenty groups on the other side. Every next model that approaches this level will open another wave of weaknesses that were described in theory for years but weren’t worth exploiting. “Technically possible, practically not” is becoming simply “possible.” OpenAI itself expects a sharp increase in such findings in the coming months, and I have no reason to doubt them. The question isn’t whether, but how quickly one follows another.
Coordinated disclosure is fragile. The entire Patch the Planet process, months of quiet work, an embargo, a synchronized release, was broken by one anonymous post. Models that churn out bugs faster also widen the circle of people through whose fingers the information can slip. A process that worked for a handful of insiders will come under pressure.
The symmetry between attacker and defender comes down to who deploys AI first. The same model that finds a hole for the defender finds it for the attacker too. The head start is measured in hours. Whoever has better tools and deploys them more aggressively wins the window. And that applies to both sides.
What to do about it here
For a sole proprietor or small business in Czechia, the practical takeaway is simple. If your website runs on shared hosting (Wedos, Forpsi and the like), find out whether and when the provider updated PHP. That’s their job, and decent hosts did it within a day. If you run your own PHP on a VPS, update immediately to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. And if you’re running PHP 8.1 or older, for which no fix will be released, you have a problem that updating won’t solve. Only migrating to a newer branch will, or taking the site off the internet until you can.
One note at the end, so it’s clear what doesn’t belong here. On the same day, October 21, the Railway platform disclosed its own security incident, a leak of environment variables containing API keys. It’s unrelated to php2shell; it’s a different wave of attacks aimed at AI inference providers. The irony is in the contrast: php2shell is an exploit that AI helped create. Railway is an attack that targets AI. Both on the same day, and both are a harbinger of what security will look like in the coming years.
And a second note at the end: I’d like to go to sleep now after a sleepless night. I had to rotate all the secrets in Railway and go through all my servers. Even with the AI agent Dijkstra it took a lot of work. But I’m off to teach an AI training… Remember, Make no Mistaikes!
Sources: Wiz Research, Calif, OpenAI Patch the Planet, Cloudflare, CISA, Sansec, SecurityWeek, CNN. Current as of October 22, 2026; the situation is evolving by the hour.
