PHP 7.4.33 (cli). That's the banner I'd bet is still printing on a frightening number of production boxes this week. 7.4.33 was the last release that branch ever got, and the 7.4 line stopped receiving security fixes in November 2022. Keep that version string in mind while the headlines argue about artificial intelligence, because it decides whether CVE-2026-109618 and CVE-2026-109619 are a bad Tuesday for you or a breach notice.

Here's what has been reported. Two flaws in the PHP engine are rated 9.2 and allow remote code execution with no authentication. The bugs are said to be more than a decade old, and the fix reportedly needed a significant change to the engine itself. Wiz found them together with OpenAI's GPT-5.6 Sol, working inside a program called Patch the Planet. Palo Alto Networks counts more than 22.6 million exposed instances. Nicholas Weaver told Cybersecurity Dive that exploitation has already been seen in the wild. Details leaked on social media on a Tuesday, so the emergency release went out a day ahead of schedule. Finland pulled its public state services offline, the Dutch national cybersecurity agency took its own site down, French prefecture sites went dark for a while, and Wikimedia briefly lost some systems. I'm passing these along as reported. Check the advisory on php.net against your own stack before you trust any secondhand summary, this one included.

The figure I keep returning to is not 22.6 million. Cisco estimates that about half of internet-facing instances run PHP versions so old they no longer get security updates at all. For those servers the emergency patch doesn't exist. No 7.2.35 point release is coming to rescue them. The only option is a version jump, and a version jump on a codebase nobody has touched since 2019 is a project, not a patch.

The strongest argument against me is that the AI angle really is the story. If a model can turn up a twelve-year-old engine flaw in a few months, then finding bugs just got cheap for everyone, attackers included, and the time between disclosure and exploitation is going to keep shrinking. I agree with that. I just don't think it changes the conclusion. Picture this exact bug found the old way by a human researcher. The servers stuck on unsupported branches would be exactly as exposed, because their trouble was never that the hole went unnoticed. Their trouble is that no fix can reach them in under a week. A cheaper way to find bugs puts more pressure on that weakness. It isn't the weakness.

I also won't pretend the upgrade is easy, because I've done enough of them to know where they hurt. A legacy app that leans on each() or create_function() breaks outright on PHP 8.0, since both were removed. The dynamic properties deprecation in 8.2 fills your logs with warnings from vendor code you didn't write and can't easily fork. Then there's the extension compiled against some long-gone ABI that one person understood, and that person left in 2021. Telling a team that has been through that to just upgrade is cheap advice. But a weekend of Rector runs and broken fixtures still costs less than being one of the sites the government had to unplug.

Honestly, this is one of the few places where our ecosystem looks good if you squint. The engine got a deep, tricky fix and shipped it early under a leak, and that's a project working the way it should. Where things fall apart is downstream, in hosting images that pin minor versions forever and in agency contracts that cover building a site but never maintaining it. A Go-writing friend of mine likes to point out that her deploy is one binary. True, and she still had to rebuild and redeploy everything that linked against a vulnerable library the last time that happened. Every language has this problem. Ours just runs a bigger slice of the web, so we see it at a bigger scale.

So the lesson I'd take from October isn't that AI is scary. It's that "we're on a supported branch" has to be a standing requirement, checked as often as backups, not a hope someone signs off on during a rewrite. If your oldest production server can't move to a supported minor version within a week of an advisory, that's your real risk, whoever or whatever finds the next bug.

Which brings me to what I'd actually like to hear from you. What is pinning your oldest production box to its current PHP version: an extension, a framework major, a client contract, or just nobody owning it? And realistically, how long would it take you to get it onto a supported branch if the next advisory dropped tomorrow morning?