The PHP scramble proves patching can't run at human speed anymore
Two AI-found PHP flaws pushed governments and major sites offline. The real lesson is that discovery now outpaces patching, and the gap is where defenders lose.
AI-generated image
What does it say about the state of internet security when the responsible move is to switch your website off? That was the advice from agencies worldwide this week, and a lot of organizations followed it.
The week the safe move was to switch things off
Two critical flaws in PHP, the language behind a huge share of the web, were found with AI tools. According to the BBC, the PHP Foundation issued a fix on Wednesday, and agencies including the UK's NCSC said organizations that couldn't fix things immediately should consider taking systems offline. Finland temporarily shut down its public government web services, the Netherlands' cyber agency took its own site down, and parts of Wikipedia became unreachable. The NSA warned that these bugs often give a direct path to a server's file system or database.
The flaws had gone undetected for more than a decade. Details leaked on social media ahead of the planned disclosure, which forced a rushed announcement. Cloudflare's CTO said he was already seeing early attacks.
The bug isn't the story; the clock is
Old, deep bugs exist in every large codebase. What changed is who finds them and how fast. Wiz said frontier models let its researchers develop working exploits across multiple applications in hours. OpenAI, which says its tools helped find the flaws, wrote that the same capabilities "can also help attackers rapidly develop offensive tools and exploits."
Now compare that with the defender's side. The Record reports that one of the bugs dates back to a 2024 audit and then stalled for months as a small team of core developers struggled with compatibility trade-offs. We don't blame them. Their reasoning looks sensible for a world where nobody could weaponize the bug quickly. That world is gone.
In our view, this is the core mismatch: discovery now takes weeks or hours, while consensus-driven fixing, packaging, and then deploying across thousands of organizations takes months. Whoever sits in that gap is exposed.
Shutting sites down is a symptom, not a strategy
Pulling a site offline works, and we think the agencies were right to say so. But it's an emergency brake, not a plan. Sophos's Don Smith put his finger on the real problem: before you patch, you must find every place PHP runs, including inside content management systems, hosting platforms, and third-party products, sometimes without the organization knowing.
That is an inventory problem, and you can't solve it on the day the advisory drops. We suspect that organizations that knew what they ran could patch or isolate in hours, while those that didn't had to guess, and guessing is how you end up with a blackout.
There is also a harder group: legacy. The Record says the patches only cover PHP 8.2 and later, and cites Cisco Talos estimates that roughly 50% of vulnerable PHP systems may not receive a patch. Those operators can't automate their way out of an unsupported version. For them, the exposure window doesn't close; it just sits there. That is the underrated part of this story.
Defenders should treat inventory and speed as controls
First, treat inventory as a security control. Know every PHP instance, including the ones vendors bundle, and ask suppliers directly.
Second, automate the boring part: staged rollouts, tested rollbacks, and pre-approved emergency paths so a critical update doesn't wait for a committee. Maintainers need the same thing; the PHP Foundation says it is changing its internal structure so serious bugs reach its leadership sooner.
Third, retire unsupported versions before the next advisory, not during it.
There is a fair counterpoint. OpenAI notes that, to its knowledge, frontier AI found these flaws before attackers did, giving defenders a head start, and it has committed $1 billion in subsidized access for organizations with limited security resources. That is encouraging, though it is the company's own framing, and the leak and the early attacks show how quickly a head start evaporates. Chainguard's CEO said the industry must "figure out how to get through them faster and more coordinated and better," and we agree. OpenAI also says it expects similar findings to increase sharply in the coming months. Take that as a forecast, but a plausible one.
The verdict: this week was a rehearsal. Organizations that can patch in hours will treat the next one as a Tuesday. Everyone else will be rehearsing the blackout again.
No topics yet: start the first one.
More stories
Browser trust is still too fragile to fail this quietly
The eMudhra compromise shows that HTTPS can remain exposed outside the browser, where revocation is uneven, trust stores lag, and users have little chance to see the difference.
GitLab’s CVSS 10 flaw makes CI/CD a production system
A critical GitLab vulnerability is a reminder that developer infrastructure can become a supply-chain attack path, not merely a collaboration tool to patch later.
HTTP/3’s QPACK problem proves speed can widen the attack surface
HTTP/3 brings faster connections and multiplexing, but QPACK attacks show that protocol complexity can turn performance features into expensive failure modes.
PHP’s Emergency Patches Expose the Web’s Fragile Foundation
Two leaked critical PHP flaws are a warning that patching is only half the problem when websites depend on aging hosting, plugins and unmanaged servers.



