PHP vulnerability: why websites are going dark on purpose today

Published Updated Web & frontend News

Found via cert.europa.eu

Two critical vulnerabilities in PHP are pushing websites to go dark voluntarily today. Here in Belgium, the site of Febelfin, the federation of the Belgian financial sector, can't be reached. There's no explanation on it. In the Netherlands, Tweakers was among the sites that went down, according to NOS. /dev/null, the social network for developers I wrote about earlier this week, showed a maintenance page too. They patched first, so that “the only remote code running here is ours”. Both are back online now.

What's going on with PHP

CERT-EU, the cybersecurity team of the EU institutions, warned today about CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10 and can lead to remote code execution: someone runs their own code on your server without logging in. Details leaked on 20 October, ahead of the planned disclosure, Sansec writes.

The patch is out now. PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and calls updating the only safe choice. Linux distributions got the patches in advance. Later today, more details emerged about the discovery and the collaboration behind the patches.

Sources disagree on whether the flaws are already being exploited. Patchstack has reports of attacks from hosting partners, while the Dutch National Cyber Security Centre (NCSC) hadn't seen active exploitation yet. CERT-EU advised being ready to patch immediately, and isolating sites from the internet if you can't. Hence all the dark screens. According to Sansec, the maintenance mode in WordPress or Magento doesn't help, because PHP already processes the request before the site checks for that mode.

Two months of work before disclosure

OpenAI describes how it helped coordinate the response over the past two months with partners including Wiz and Cloudflare. PHP’s maintainers led the fixes and release. Calif found a critical flaw using GPT-5.6 Sol; Wiz also independently discovered and reported both flaws.

That is coordinated disclosure: the teams involved get time to test fixes and prepare protections before publication. According to Sansec, details leaked on 20 October. Attackers then had information ahead of the planned disclosure too. Temporarily isolating websites until the patch was installed and verified helped cover that gap.

How easy was exploitation? PHP confirms a demonstrated attack on Apache with mod_php needs just one request without a login, before any website code runs. Calif tested attacks against WordPress and Drupal, among others. The available attack paths depend on the PHP version and server configuration. These flaws are in PHP itself and require no unsafe community plugin. Whether wordpress.com or wordpress.org is protected cannot be determined from the fact that the site stays online.

PHP isn't less safe, it's everywhere

Concluding from this that PHP is unsafe, or that a website running on PHP is, goes too far for me. PHP is simply used a lot: according to W3Techs, 69.3% of websites whose server-side language is known run on PHP. That includes WordPress, Drupal, Magento and Laravel. A flaw in something that widespread hits a big chunk of the web at once, which is why so much is going offline together.

Belgian municipal websites are built with Drupal too. iO chose it for Mechelen’s new city website, for example. This affects local services too. VRT NWS reports in its liveblog that Ghent was among the cities that took its website offline as a precaution. At the time of this update, chat services at Awel, Tele-Onthaal and Zelfmoordlijn were also unavailable. Their phone lines remained available. A site going offline does not necessarily mean it was hacked; these organisations are taking precautions.

AI is hunting for vulnerabilities too

Finding these flaws with AI fits what's noticeably happening. We build a lot with artificial intelligence (AI), me included, but AI is just as constantly being used to find vulnerabilities. Greg Castle from Kubernetes wrote on the CNCF blog in April that it's now “trivial” for non-experts to find real vulnerabilities. On 1 October Google stopped accepting reports for its open source bug bounty, after a flood of automated submissions, most of them invalid.

This is becoming a new online battle, and open source is feeling the pressure. Software like PHP is often maintained by a community and certainly isn't always paid for. Those teams do everything they can to keep their software user-friendly and secure, and now get reports coming in at machine speed. Crazy times.

Updates and maintenance contracts

This shows once again how important it is to update websites and platforms regularly. A PHP fix only helps once someone installs it. PHP itself only supports version 8.2 and up. This time the security team did put minimal source fixes online for 7.4, 8.0 and 8.1, but if you run one of those, you have to build it yourself or ask your vendor.

That's what maintenance contracts are for. They exist for a reason.

Our hosting partner GeNx alerted us proactively. In consultation with our clients, they also took critical websites offline to prevent things from getting worse. Many website owners don’t even know their site runs on PHP and have no idea anything is wrong. Having a hosting partner who follows the situation closely and gets in touch makes a real difference.

Thanks to Sam and the GeNx team for keeping on top of it. Good service matters, especially on a day like this.