The PHP Vulnerability: An Early Example of AI-Led Attacks
23rd October 2026 | by Matt Fooks
4 Minute Read
How AI found a decade-old flaw in the software behind most of the world's websites, why it is a sign of what is to come, and what it means for the rest of your IT.
Executive Summary
As has been widely publicised, earlier this month two flaws in PHP, the software behind roughly 70% of the world's websites, were made public. They let an attacker run their own code on a web server without needing a password or an account, so organisations including government departments took their sites offline to apply the fix. The flaws had sat in the code for more than a decade. AI found them in days.
When a fix is published by a software provider, it shows attackers where the flaw is. AI can then work out how to exploit it, find who has not yet updated, and attack at scale, in minutes rather than weeks. Details of this one leaked early, and attempts ran into the millions within days.
That gap between a fix being published and applied is what has made patching manageable up until now. AI is closing it. This time it was websites, because websites are public. But it also affects all business systems and software.
What Was Different About This Attack
The flaws were found by AI, in code that people had been reviewing for more than ten years.
Two security firms found them independently in August, and kept them confidential while a fix was built. Finding a flaw is only part of the job; proving it can be exploited is the harder part, and has historically taken skilled people weeks or months. The AI did that too, working out a reliable method of attack by trial and error.
Both sides have always hunted for vulnerabilities: vendors to fix them, criminals to use them. Until now both worked at human pace. That is what has changed.
The Window Has Shrunk
Software vendors and their customers have handled vulnerabilities broadly the same way for decades. A flaw is found and kept confidential while a fix is built. Both are then published together, and organisations schedule the update, because applying it usually means downtime on something important.
During that period you are technically exposed, but the risk has been acceptable. Criminals needed time to understand a new flaw, build a working attack, find vulnerable organisations and reach them at scale.
That no longer holds. The leak forced the fix out a day early, and attempts to exploit the flaw had been detected four days before that, by means nobody has yet explained. Within 45 minutes of the announcement, one major internet infrastructure provider was recording tens of thousands of attempts. Within days, millions.
This is the pattern, not the exception. Around a quarter of newly exploited vulnerabilities are attacked on or before the day they become public. The average organisation takes roughly 55 days to fix a serious one.
Why This Affects Every System, Not Just Websites
Everything a business runs on is software: firewalls, phone systems, networks, backup, finance and operations platforms, laptops. All of it contains flaws nobody has found yet. The methods that found the PHP flaws work on any of it, and are as available to criminals as to the companies that build it.
The scale is already clear. In April, Anthropic launched Project Glasswing, giving an AI model called Claude Mythos to companies including Cisco, Microsoft, Google and AWS to find and fix flaws in critical software before criminals did. Within a month it had identified more than 10,000 serious vulnerabilities. Cisco, one of our principal partners, reviewed 1.8 billion lines of its own code in eight weeks, work it estimates would have taken eight years.
These flaws are being found by the right people, which is the point. But each one becomes a fix somebody has to apply, and a period during which systems are exposed.
How the Industry Is Responding
Finding flaws is no longer the hard part. Applying fixes is.
The most promising answer is protection that works before a fix is applied, shielding a vulnerable system so it cannot be exploited while the fix is tested and scheduled. Cisco and Palo Alto Networks are both developing systems of this kind, testing them with a small number of partners, VCG among them. Neither is generally available yet. Disclosure practice is changing too, with vendors bundling related issues into fewer, larger updates.
For systems management, this means rebuilding how patching works. Fully automatic patching sounds attractive but will not always be practical: fixes still need testing, and critical systems still need maintenance windows. The workable answer combines faster patch cycles, automation where it is safe to use, and shielding to cover the gap.
What to Expect Next
The patching load will rise sharply. AI is finding flaws faster than vendors can build fixes or customers can apply them, and that backlog has to go somewhere.
The gap between a flaw becoming public and being attacked will keep narrowing. Attacks that arrive at disclosure, or before, as they did here, will become less unusual.
Expect a wave of new tools and services aimed at this problem. Shielding, autonomous patch management and faster response tooling will move from pilot to mainstream, and the managed services built around them will follow.
Until they arrive, the most effective thing you can do is reduce the exposure you already carry: retire out-of-support software, review network structure and backup design, and make sure your security monitoring, resilience and response arrangements are comprehensive.
What to Do Now
Four things matter most.
Act quickly on patching advice. The tolerance for delay that existed two years ago has gone.
Deal with technical debt. When a system goes out of support, fixes stop and its flaws stay open permanently. Keeping it running can look like sound commercial discipline while becoming one of the larger risks the business carries. We believe in getting full value from an investment, but once something reaches end of life that calculation changes.
Look at how your network is structured. A flat network lets an attacker who gets in reach everything. Separating it limits what any single breach can touch.
Check your backups. Outdated backup design is one of the most common reasons a ransomware incident becomes severe, usually because the backups sat on the same network as everything else.
Review and strengthen your security and response arrangements. This should be routine practice anyway, but as AI tools and AI-driven attacks continue to evolve, security becomes even more important. Monitoring that detects an intrusion quickly, and a response plan that has been tested rather than written, are what limit the damage when something does get through.
Talk to Us
If you want a view on where your own exposure sits and what to prioritise, get in touch through our contact form.
Sources
Latest Insights
Resource, Insight and guides from industry thought leaders.
