On 21 October 2026, Germany's digital ministry took some of its websites offline. France's Interior Ministry deactivated sites for local administrative offices. Authorities in Belgium, the Netherlands, Finland and the Czech Republic did the same. The US National Security Agency also issued a warning; according to Al Jazeera, it advised taking websites offline if they could not be updated immediately.
The reason was two bugs in PHP, the programming language that runs most of the world's websites. According to the researchers, the vulnerable code had been in PHP for more than a decade. Researchers working with artificial intelligence showed that it could be used to take over a server, although, as the PHP Foundation later explained, one of the problems had first been noticed in 2024.
This is a story about more than one emergency patch. It is about how the hunt for software weaknesses is changing — and why that matters to defenders and attackers alike.
What PHP is, and why it touches almost everyone
PHP is a language for the server side of websites: what happens "behind the scenes" when you open a page, type a password or submit a form. Popular content management systems — WordPress, Drupal, Joomla — are built on it.
According to W3Techs, as of 22 October 2026 PHP is used by about 69% of websites whose server-side language can be identified. That is where the headline figure of "70% of the internet" comes from. It is approximate: it counts websites, not traffic or data, and not all of those sites were equally exposed.
An ordinary visitor never sees PHP. But if a site they use is compromised, the consequences can reach them too: leaked data, a defaced page, a malicious link.
What actually broke
The flaws were assigned CVE-2026-109618 and CVE-2026-109619, and the researchers named them PHP2Shell. Both were rated 9.2 out of 10 for severity on the CVSS 4.0 scale.
Put simply, the problem lies in two places in how PHP handles a request from a browser:
- when memory runs out while a request is being processed, PHP leaves behind "debris" that its clean-up routine later trips over;
- a PHP worker process can reuse leftover state from a previous request.
Picture a waiter who sometimes doesn't clear the table after the last guest, so the next guest can use whatever was left behind. Each lapse on its own is minor. But the researchers showed how to chain them: send the server a specially crafted request and make it run commands of your choosing.
Two things make this especially dangerous. First, no password is needed: PHP processes the request before the website's own protections kick in. Second, according to Wiz, nearly every PHP version is affected by at least one of the flaws, going back to 5.4, released in 2012. Versions up to and including 8.1 are no longer officially supported: for them the PHP team published only minimal source patches, and some Linux distributions ship their own fixes.
Who found it, and how
According to researchers at the security company Wiz, events unfolded like this:
- 19 August — the first flaw is found;
- 20–21 August — they confirm it can be used to take over sites running Drupal and WordPress;
- 24 August — they report it to the PHP security team;
- 21 September — PHP acknowledges the problem and starts work on a fix;
- 21 October — patched versions are released and the details made public.
But Wiz was not first. The company Calif, working with OpenAI, says it found one of the flaws earlier using GPT-5.6 Sol and reported it on 11 August. Wiz says it found the flaws independently.
Part of the story is older. According to the PHP Foundation, as reported by The Record, the history of CVE-2026-109618 goes back to 2024, when PHP had its first external security audit in several years: at the time no way to exploit the problem was known, and no action was taken. Developers also disagreed on how to fix it without breaking compatibility, and the work stalled. The August reports made the full impact clear, and from 11 August fixing it became the top priority for the foundation's security team. The foundation adds that OpenAI, Wiz and Trail of Bits found the same flaws independently during audits of PHP.
Wiz says it used its own tool, Wiz Atlas, together with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol language models throughout. According to the researchers, the models helped find the flaws, write and adapt the exploit — a program that uses a vulnerability — for different PHP versions, and check the fixes. They claim one specialist did in a week what would previously have taken a top-tier team months.
The distinction matters here. That AI helped researchers find an exploitable chain and build the exploit is an established fact: everyone involved says so, and the vulnerability itself is real. "AI found the bug" is a simplification: at least part of the weakness had been noticed before; what was new was the proof that it could be exploited, and the speed. How much the models did versus the humans, and how much faster the work went, is the companies' own estimate.
Wiz is owned by Google, so both firms whose models were used have an interest in a big story. There is no independent account yet of how the work was divided.
Why governments switched sites off
Critical vulnerabilities are usually disclosed in a coordinated way: first the fix, then the details. This time the plan broke down. According to SecurityWeek, details leaked online before the scheduled patch release.
On 20 October, PHP warned that the fix would come the next day and urged administrators to get ready. Security experts predicted mass attack attempts within minutes of publication. Companies later reported seeing exploitation attempts, including before the patches were out.
Cloudflare counted tens of thousands of attempts within 45 minutes of disclosure and millions by the morning of 22 October. Some attackers tried, unsuccessfully, to use the flaws to spread Potassium, a variant of the Mirai botnet malware.
For an administrator of a government website, the choice is simple: if the server cannot be updated right away, a few hours offline is safer than risking a break-in. Hence the headlines about websites "going dark".
Britain was affected too. On 22 October a government minister told the House of Lords that 32 government digital services were unavailable and four more partly unavailable, largely as a precaution. The National Cyber Security Centre sent warnings to more than 50,000 UK organisations.
As of 23 October, security firms report no confirmed successful break-ins. But it is early: real consequences usually emerge weeks later.
Not the first time AI has hunted bugs
In November 2024, Google's Project Zero team reported that its AI agent, Big Sleep, had found a previously unknown vulnerability in SQLite, a widely used database. The bug was fixed the same day, before it reached an official release. At the time the authors cautiously wrote that they "believe" it was the first public example of its kind.
In two years, the scale has changed. Then: one bug, closed before it could harm anyone. Now: a chain of flaws in the foundations of most websites, together with a working attack.
On a maturity scale, this is no longer a lab demonstration: using AI to find vulnerabilities exists and works now. The open question is how widely it will be used, and who will make use of it first.
A tool for both sides
What follows is interpretation, not fact.
The same capability that helped Wiz and Calif is available to people looking for flaws to attack. The Wiz researchers say so directly: complexity "may no longer provide a meaningful barrier". Many dangerous bugs used to go unnoticed simply because they were very hard to find and exploit. If AI lowers that barrier, old code across the internet may turn out to be less safe than it seemed.
But the two sides are not equal. An attacker needs to find one unpatched server. Defenders need to update all of them. So the bottleneck shifts from finding bugs to fixing them: someone has to write a patch, test it and install it on millions of servers, some of them running versions that are no longer supported.
There is a human side too. Many basic internet technologies, PHP among them, are maintained by relatively small teams. If AI uncovers more and more serious bugs, the load on those people will grow.
What we still don't know
- How many systems are still unpatched, and how many were actually breached. As of 23 October, Censys estimates that more than 34 million PHP services (web services, not physical servers) are still vulnerable; there are still no confirmed mass compromises.
- Whether others found these bugs first. The vulnerable code existed for more than a decade, and one of the problems was noticed in 2024. Nobody knows whether someone was quietly using them. Amazon says its honeypot network recorded an exploitation attempt on 17 October, four days before disclosure; how the attacker got the details is unknown.
- How much of the work was AI's. Only the participants have said.
- How many similar bugs are still waiting. If AI found this in PHP, it is reasonable to assume similar flaws exist in other old technologies. But that is an assumption, not an established fact.
Three plausible scenarios
Defenders pull ahead. Companies and open-source developers use AI to audit old code at scale and fix bugs before attackers find them. Condition: access to such tools, and people able to ship fixes fast enough.
An even race. Emergency patches like PHP2Shell become a routine part of life, and the gap between disclosure and the first attacks shrinks to minutes.
Updating is the bottleneck. Bugs are found quickly, but old, unpatched servers remain the weakest point, and the most important skill becomes updating fast.
These scenarios are not mutually exclusive. Most likely, different parts of the internet will play out differently.
What this means for you
If you run a website — on WordPress, say — ask your hosting provider whether PHP has been updated. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or newer. If your site runs on PHP 8.1 or older, there will be no official release with the fix — only patches for those who build PHP themselves, or fixes from some Linux distributions — so it is worth planning a move to a supported version.
If you simply use the internet, there is nothing special to do. But this is a good moment to switch on automatic updates on your phone and computer, and to be wary of emails along the lines of "urgently update your website" — scammers love a big news story.
The main lesson is simple: in security, the winner is not whoever knows about every bug, but whoever fixes them quickly.
Questions for discussion
- Is it right to switch government websites off for a few hours for the sake of security, if people can't access services in the meantime?
- Who should be responsible for the security of technologies the whole internet relies on but that relatively small teams maintain?
- Does AI's role change how you see this story: is it mostly good news for defenders, or a warning sign?
Log in or Sign up to join the discussion.