A flaw in PHP itself took websites offline as a precaution
On 21 October PHP released an update for two critical flaws. The Dutch NCSC advised treating every website that runs on PHP as vulnerable until that update is installed.
What happened
On 21 October PHP released an update for two flaws that let an attacker take over a web server without logging in. Because details had been circulating since the day before, organisations across Europe took their websites offline as a precaution.
On 20 October PHP announced the update for 14:00 UTC the next day, rating both flaws 9.2 out of 10. By around 15:00 UTC their official numbers were already circulating on forums and social media, with the wrong time and an inflated score. That evening Calif, one of the firms that found the flaws, accidentally posted a video of its attack working against real websites. Copies kept circulating, according to the PHP Foundation.
On 21 October Cloudflare saw the first attacks at 07:43 UTC. From 10:48 UTC, DigiD (the Dutch government login), the MijnOverheid citizens’ portal, the Dutch House of Representatives, broadcaster RTL, the Dutch football association and several hospitals went dark. In Flanders, every government website went offline.
Around 14:00 UTC PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 came out. Most sites were back that evening: MijnOverheid at 16:11 UTC, DigiD at 18:27.
How much damage was done is not yet clear. According to Fortune, Cloudflare counted tens of thousands of attack attempts within 45 minutes of the news getting out, and millions by the evening of 21 October. AWS says it saw attempts days earlier and speaks of broad exploitation. The Dutch NCSC and justice minister Van Weel had seen no active exploitation in the Netherlands that day.
Treat every website that runs on PHP as vulnerable until the update is installed.
The NCSC’s advice of 21 October 2026, in short
The background
How the flaw works
PHP handles each request to a website in a worker process, which then picks up the next request. Each request gets its own slice of memory, which is cleared afterwards. Things go wrong when a request is cut off halfway, for example because it asks for more memory than allowed. PHP then stops before everything has been cleared, and some pointers still point at memory that has already been freed. The next request in the same worker then uses it.
With a carefully chosen series of requests, an attacker can read that memory, which may hold other people’s passwords and keys, or run their own code. The attack uses the kind of request that submits a form or uploads a file, which PHP processes before the website’s own code even runs. According to Wiz, that is why even a test page that only says ‘Hello World’ can be vulnerable. The risk is highest when PHP runs as a module inside the Apache web server (mod_php).
Found with AI, fourteen years on
The vulnerable code has been in PHP since version 5.4, released in 2012. In 2024 a developer had already spotted the memory problem while working on PHP’s first external security audit, but nobody found a way to exploit it at the time.
Calif, part of OpenAI’s Patch the Planet programme, found the first flaw on 1 August with the AI model GPT-5.6 Sol and reported it on 11 August; OpenAI reported the same root cause that same day. Wiz independently found its first flaw on 19 August, using Google’s Gemini 4 Argon, GPT-5.6 Sol and an AI tool of its own. According to Wiz, AI did the painstaking part: adapting the attack to every PHP version and setup. That way a single researcher did in a week what used to take a top team months.
Earlier flaws in PHP
PHP has had serious flaws before, but they hit particular setups. In 2024 the researcher Orange Tsai found a way on Windows around a fix from 2012 in CGI mode, an older way of running PHP. Two days after the update, the TellYouThePass ransomware group was already using it.
This time it affects every installation that serves web requests. According to W3Techs, 69.3% of websites whose server-side language is known run on PHP. Of those, 65.3% use version 8, 26.9% version 7 and 7.7% still version 5. PHP itself only releases updates for 8.2 and newer.
Our analysis
AI sped up finding the flaw; fixing it was still down to people
With AI, two companies found the same flaw within three weeks, after it had gone unnoticed for fourteen years. Fixing it took more than two months. The PHP Foundation itself calls that a structural failure: a small team had to agree fully on fixes that each caused a new problem, and it was short of people. AI helps defenders and attackers alike find flaws faster, but the software under a large part of the web rests on a handful of paid developers and volunteers. Our expectation: more flaws like this will surface in old foundations, and the time between disclosure and attack will keep shrinking.
At the same time, ‘70% of the internet’ overstates it. The figure is PHP’s share of websites, not the number you can take over. According to Sansec, the public attack code mostly fails against a default installation, and an attacker usually also needs a second flaw in the website. Millions of attempts are not millions of break-ins. But a working attack on mod_php exists, and leaked memory can give away passwords and keys.
The biggest risk lies in old versions. More than a third of PHP sites run on version 7 or older. For 7.4, 8.0 and 8.1 PHP only released a fix as source code, not a ready-made update, and for older versions nothing at all. Sites running them depend on a host or vendor that builds in a fix itself, or are left empty-handed.
What stands out
- The finders gave the attack away Calif accidentally posted a video of its attack. The software supplier Chainguard released fixed builds more than six hours early, which attackers could compare with the old ones.
- The big players were prepared According to Wiz, Cloudflare, AWS and Microsoft prepared defences in advance, and Linux distributions got the fix early. A volunteer-run source of PHP packages had nothing that day.
- From now on, PHP votes The security team will now decide by majority. The PHP Foundation is asking companies, hosting providers and governments to help pay for the work.
- Reports are piling up Since early July PHP has published 15 flaws and worked through more than a hundred invalid or duplicate reports, with a small group of developers.
What it means for you
Does your website, webshop or customer portal run on PHP? Then it is vulnerable until the update is in place.
- The flaw is in PHP itself So updating WordPress or plugins does not help. Only the new PHP version closes it.
- Ask which version is running Your hosting provider or developer can tell you in a minute. Lower than the versions above? Then something needs to happen now.
- Beware of emails from your host Criminals pose as hosting providers and ask for login details. Always sign in yourself, the way you know.
Where we come in · Support
We check with you whether your sites are safe yet
Sites hosted with us got the update the same day. If your site lives elsewhere, we help you find out which PHP version is running and what needs to happen. With Support, we then keep watch for flaws in what your colleagues build themselves.
Not sure your site has been updated yet?
Send us its address. We’ll look at it with you and always reply within one working day.
