Security: an AI found a flaw in 7 out of 10 websites, is your site safe?

This week, Dutch and Finnish government websites disconnected themselves. No hacker in the server room, no outage: a decision made on purpose, while waiting for a fix. The GrapheneOS forum (an Android version for privacy nuts), Pinboard (a service for storing your bookmarks) and part of the OBS website (the software all streamers use to record their screen) did the same. CERT-EU, the team that watches over the IT security of European institutions, outright advised shutting off anything that couldn't be updated right away. All this over two vulnerabilities in PHP. And these two vulnerabilities were found by AIs.

Shutting down your own website is rare. It happened all over Europe this week

What PHP is, and why everyone jumped

PHP is the engine that builds the pages of a large part of the web. When you open your baker's blog, the online shop of the local garage or a Wikipedia page, there's a good chance a PHP program is building the page on the fly, just for you. WordPress, Drupal and Joomla, the three big pieces of software used to make websites without being a developer, all run on it. Wiz, the security company that revealed the story on October 21, estimates that PHP powers seven out of ten websites around the world. That's its figure, but all the surveys land around there.

And the problem is in PHP itself, not in a module you forgot to update. According to Wiz's analysis, every version from the last decade is affected by at least one of the two vulnerabilities, and even a page that only displays “hello” may be enough. The researchers managed to take complete control of servers running WordPress, Drupal and Joomla, without a password and without an account. They called it PHP2Shell: “from PHP to the command line”, that is, from the web page to full control over the machine.

PHP Foundation security manager Volker Dusch told the Wall Street Journal that it was the most serious problem PHP had faced in more than ten years. He compared it to Heartbleed, the 2014 vulnerability that had pushed millions of people to change their passwords. That sets the tone!

The coat check that gives you someone else's coat

Imagine a theater coat check. The attendant takes the coats, hangs each one on a numbered hook, and gives you a ticket. Normal.

Now, one busy evening, the attendant is overwhelmed. He clears a hook to make room, but forgets to cross out the number in his notebook. The next customer arrives with a carefully chosen ticket, the attendant looks at his notebook, and hands him whatever is hanging on the hook: someone else's coat, with their keys and wallet in the pocket.

The ticket doesn't match, but the notebook says yes

That's exactly what happens in PHP. When a server runs out of memory in the middle of a job, PHP frees a memory slot but keeps a little note that still points to it. The next request, which can come from anyone on the Internet, lands on that outdated note. Depending on how it goes about it, it can read what the previous visit left behind (someone else's coat), or slip its own instructions into the slot so the server executes them (slipping a fake ticket into the notebook). And to cause a crush at the coat check, all it takes is sending the server a payload that's a little too big. Bam.

Who found them: AIs, and humans who knew where to look

This is where the story gets really interesting. In August, two teams stumbled across them, each on its own. First came Calif, a team paid to attack software before the real hackers do, which was auditing PHP's code with GPT-5.6 Sol, an OpenAI model. OpenAI paid for the audit as part of a program called Patch the Planet (“patch up the planet”). Then Wiz, which now belongs to Google, with its own tool and two models: Google's Gemini 4 Argon and, again, GPT-5.6 Sol.

Two months of keeping it secret, and the leak arrives the day before

What I like is that nobody is saying that AI did everything all by itself. Wiz explains that the models mainly served to turn a discovery into an attack that really works: adapting the trap to each version of PHP, understanding why an attempt failed, starting over. The kind of painstaking work that used to take months. According to Wiz, a single researcher wrapped it up in a week. And Calif, for its part, insists: they used models that anyone can buy, without any special tool, and what mattered most was knowing the history of PHP and its old bugs. Their sentence, in French: “no model digs up ‘all the bugs’ with simple instructions.”

In other words, AI does not replace the researcher, it gives them ten arms. That ties in with what I was saying at the beginning of September when OpenAI, Google and Anthropic released their AI that hacks on the same day : these tools were announced for defenders, and this time, they really were the ones who fired first. OpenAI says that as far as it knows, the vulnerabilities were found by AI before they were found by attackers.

Two days of panic all the same

The plan was neat: two months of secret work with the PHP team, Cloudflare, Linux system publishers and the US authorities, then a release at a fixed time, on Wednesday, October 21 at 4 p.m., Brussels time, so everyone could update at the same time. Except that details leaked beforehand, in a discussion on Hacker News, the big developers’ forum. As a result, PHP brought its release forward, and the hackers’ workshop opened earlier than planned.

Cloudflare, the company that protects and speeds up a huge portion of the world’s websites, activated filtering rules for all its customers, including free ones, at 5:02 a.m. (Brussels time), nine hours before the release. And its teams watched the attackers modify their requests live to get through. watchTowr, another security company, confirmed attack attempts on both vulnerabilities, according to The Next Web. Meanwhile, Laravel, one of PHP developers’ favorite tools, froze its customers’ deployments while everything was rebuilt with the fixed version.

And OpenAI, being a good sport, announced a billion dollars’ worth of subsidized access to its security tools for organizations that cannot afford to pay for them in its post that same day. It also warns that this kind of discovery is going to “increase sharply in the coming months.” We’ve been warned.

Concretely, is your site affected?

If you have a WordPress site, an online store or a blog with a standard hosting provider (OVH, o2switch, Hostinger, Infomaniak and the others), it is almost always your hosting provider that installs PHP, and it is therefore up to them to perform the update. But do not just assume it: go to your customer area, look for the line “PHP version,” and check the number.

Five minutes in your customer area, and you know whether you can sleep easy

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or later. If you see 8.1, 8.0, or worse, some old 7.something, that is where things get ugly: the PHP project no longer fixes those versions. Some hosting providers and Linux publishers still apply the fix on their side, so ask them the question in writing. And if they do not give you a clear answer, take the opportunity to move your site to a recent version: your WordPress had probably already been asking you for it for months.

Why bother for a small site that contains nothing important? Because a hacker who takes control of your server does not necessarily want your data. They want your machine: to send thousands of scam emails in your name, host a fake banking page, or serve as a relay to attack someone else. And it is your domain name that ends up on the blacklists.

And if you don't have a site? You have nothing to do. As a simple visitor, you risk nothing by opening a page, the flaw targets servers, not your browser. The only effect you might see is an administrative site “under maintenance” this week. Now you know why.

For the little story, the site you're reading me on runs on .NET, not PHP. For once, twenty-five years of .NET are serving as my umbrella!

If you're a developer

You can skip this part if you don't manage a server. The two flaws have the official numbers CVE-2026-109618 and CVE-2026-109619 (the license plate of known flaws), and PHP gives them 9.2 out of 10 in severity. The PHP Foundation specifies that all installations that serve pages are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The most exposed case is mod_php, where an anonymous request can trigger the problem before your code even starts. Watch out for a classic trap: the PHP version you see in your terminal isn't always the one your web server uses. Check both, the second one on a diagnostic page from your host or your administration panel. In the terminal, it looks like this:

php -v
php -i | grep -i "upload_progress"

Wiz recommends watching for three signs of an attack: uploads in several pieces followed by memory errors or bursts of 500 errors, abnormally long or malformed PHPSESSID cookies, and PHP processes restarting for no reason. The emergency settings going around (disabling session.upload_progress, reducing post_max_size, setting display_errors to zero) reduce the risk, but PHP says it in black and white: only updating fixes the problem. And once you're up to date, check whether someone hasn't already got in. As Madelein van der Hout, an analyst at Forrester, points out: a patch closes the door, it doesn't get the person who's already in the house out.

My opinion

I find this story rather reassuring, and that surprises even me. A flaw hidden for years in the engine of seven out of ten sites, found by defenders armed with AI, fixed in two months with everyone around the table, and sites shutting themselves down as a precaution rather than crossing their fingers: that's exactly how it should happen. The last-minute leak just shows that secrecy never holds until the end.

What worries me is what comes next. The hackers have the same models, they read the same patches, and their bots don't sleep. Less than three weeks ago, I told the story of a flaw exploited in less than a day. So the question is no longer whether it's going to happen again, but how many small forgotten WordPress sites, with their PHP 7 from five years ago, will serve as cannon fodder by Christmas. Come on, go check your version, it takes five minutes!

Sources

• Wiz Research, October 21, 2026: PHP2Shell, the timeline, the four bugs and the applications affected
• OpenAI, October 21, 2026: Patch the Planet, coordinating the response to PHP vulnerabilities
• The Next Web: PHP releases emergency patches for two vulnerabilities first found by AI
• CSO Online: two critical PHP vulnerabilities put the web on alert
• Tenable: frequently asked questions about PHP2Shell

Article written with the help of Claude Code, reviewed and corrected by me.