Factsogy

Tech ·

The PHP Flaws That Made a Country Switch Off Its Websites

Two critical flaws in PHP leaked a day before their fix, and Dutch organisations from parliament to DigiD took their own websites offline as a precaution.

Key facts

  • The survey firm W3Techs counts PHP on 69.3 percent of websites whose server language is known: about seven in every ten.
  • WordPress alone powers 39.6 percent of all websites, W3Techs says.
  • 35.1 percent of WordPress sites run PHP versions the PHP project no longer patches.
  • Jonathan Desrosiers, a core committer of WordPress, acknowledged that nearly 17 percent of all WordPress sites still report PHP 7.4.

Transcript

On Wednesday, the Dutch state took its own websites offline: parliament, DigiD, even the national cyber security centre. Switched off on purpose, as a precaution. This is how two leaked flaws in PHP made Dutch websites go dark. How did a secret meant for Thursday get out on Tuesday? And would the fix, promised for four o’clock, protect everyone?

Tuesday, 20 October. A post appears on Hacker News, the forum where programmers trade news. It says two critical flaws in PHP are about to go public, and cites only what it calls a reliable source. The post is then taken down. Too late. Screenshots are already going around social media.

Then the security firm watchTowr confirms the leak. The flaws were under embargo, and it writes: we were all supposed to wait until Thursday at 11am Eastern. Its chief executive, Benjamin Harris, puts it plainly: these vulnerabilities are indeed real.

Shortly after, PHP’s own security team posts an advance notice. It announces an emergency release for Wednesday at 14:00 UTC, a day before the embargo was meant to end. PHP’s own team rated both flaws critical, 9.2 out of 10. And it warns it may ship even sooner, if details spread or attacks begin.

Then claims of a working exploit begin to circulate. Kirill Firsov, a technology chief at the firm FearsOff, shares a demo video on X under one word: php2shell. He credits the exploit to the California firm Calif and an X user named lcfr_hax. A screenshot of a tool with the same name claims to work on every PHP release since version 5.4. So that is how a secret meant for Thursday went public: one post, then screenshots across social media. Wednesday morning, Cloudflare reported early attacks, and no fix existed until the afternoon.

Why would two bugs in one programming language take a country offline? Because PHP is the engine room of the web. It powers WordPress, Drupal, Joomla and Magento sites, shared hosting platforms and control panels. The survey firm W3Techs counts PHP on 69.3 percent of websites whose server language is known: about seven in every ten.

Now picture what remote code execution means. Remote code execution would mean an attacker can make a server run commands of their choosing. PHP is what lets websites handle logins, payments and databases, the Dutch cyber security centre explains. Its verdict: until they update, organisations running PHP on their web servers face a very high risk of complete takeover.

So how many machines are we talking about? Security researcher Silas Cutler’s rough estimate: over 1.3 million servers on the open internet may be vulnerable. Cloudflare, which stands guard in front of many popular websites, rushed out firewall rules on Wednesday. Its technology chief, Dane Knecht, called them a stopgap only.

And then there is WordPress, the platform behind a huge slice of the web. WordPress alone powers 39.6 percent of all websites, W3Techs says. Its own statistics hold the bad news. 35.1 percent of WordPress sites run PHP versions the PHP project no longer patches.

Wednesday, 14:00 UTC. Four o’clock in Amsterdam. That is the hour PHP promised its fix. The security firm Sansec made a grim forecast: mass attacks within 15 minutes of the release. PHP’s own advisory confirmed it: the flaws can let an attacker run code on a server without logging in.

And the fix comes with a catch. When PHP shipped the fix on Wednesday, it came only for version 8.2 and newer. Servers on PHP 8.1 or older get no official fix.

Older is everywhere. Jonathan Desrosiers, a core committer of WordPress, acknowledged that nearly 17 percent of all WordPress sites still report PHP 7.4. At WordPress’s scale, he wrote, that means many millions of sites. The PHP project stopped patching 7.4 back in 2022. Oliver Sild, the chief executive of the security firm Patchstack, said his whole company went into emergency mode.

So the advice from inside PHP is blunt. Core developer Gina Peter Banyard says patching is the only mitigation. If an owner can afford a day offline, she calls taking the server offline the most sensible option. Several Dutch organisations did exactly that on Wednesday. Reacting to the news, GridPane CEO Patrick Gallagher wrote: “This is fairly horrifying.”

So the leak beat the fix by a day, and the fix leaves a gap. Servers on supported versions can be patched; older ones need an upgrade, or a backport from their provider. The Dutch cyber security centre’s advice is simple: install the updates as soon as they are available.

Sources

  1. sansec.io: Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
  2. Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)
  3. nos.nl: Websites van overheid en in onderwijs offline vanwege lek, risico op hacks
  4. rd.nl: Allerlei websites offline om waarschuwing PHP, nog geen misbruik gesignaleerd
  5. securityweek.com: PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
  6. Tenable®: php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ
  7. watchTowr: PHP Remote Code Execution FAQ: CVE-2026-109618
  8. php.net: PHP
  9. therepository.email: Exploit Claims Surface Ahead of Critical PHP Security Release as WordPress Community and Hosts Scramble
  10. Wikipedia: PHP
  11. Brandefense: PHP2Shell: PHP RCE CVE-2026-109618, 109619
  12. cyberdaily.au: Alert! PHP preparing to address pair of critical RCE vulnerabilities
  13. github.com: RCE via OOM corruption

How we research and check stories: editorial standards. Spotted an error? Report it.