rkj dev

European Websites Go Dark as Admins Patch Critical PHP Vulnerabilities

Two critical remote code execution flaws in PHP prompted emergency shutdowns and rapid updates across European government and public services.

Illustration of a systems administrator working in a server room under amber alert lights.
Illustration: Systems administrators across Europe performed emergency maintenance as security patches rolled out.AI-generated illustration

In short

  • Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect all PHP web servers dating back to PHP 5, carrying CVSS scores of 9.2.
  • Government agencies and public services across Germany, France, the Netherlands, Belgium, and Finland temporarily disabled websites to prevent unauthenticated remote code execution.
  • The PHP development team published emergency updates in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, while the PHP security team provided minimal source-backports for PHP 7.4, 8.0, and 8.1.
  • A disclosure leak and accidental video upload accelerated the patch timeline by 24 hours after exploits began circulating online.

Government agencies, municipal services, and public institutions across Europe took critical web portals offline on October 21, 2026, as administrators moved quickly to patch critical PHP vulnerabilities. The emergency updates, published across supported releases of the scripting language, resolve two severe flaws that allow unauthenticated attackers to execute arbitrary code directly on web servers. The voluntary shutdowns followed alerts from European and national cybersecurity authorities, who advised operators unable to patch immediately to disconnect internet-facing systems.

PHP forms the backbone of a major portion of the internet, powering platforms such as WordPress and Wikipedia. Because the vulnerabilities allow remote attackers to compromise servers without requiring credentials, organizations chose planned downtime over leaving active services exposed to automated scanning and potential intrusion.

Emergency Disconnects Across European Public Infrastructure

The impact across Europe was immediate and widespread. As reported by TNW, CERT-EU advised organizations to take unpatched systems offline, leading multiple governments to sever connections while staging updates. In the Netherlands, officials pulled the government portal Overheid.nl, the Port of Rotterdam's public site, services for the five largest political parties, several hospitals, and even the National Cyber Security Centre's own website. Germany's federal IT provider ITZBund similarly removed several public-facing services as a preventive measure.

In France, the Interior Ministry and regional bodies took local prefecture pages and the Paris police prefecture website offline, according to The Guardian. Finnish state IT center Valtori deactivated public web services as a precautionary step, while Danish municipal agency Kombit took down school communication platforms. Disruption extended to municipal councils in the United Kingdom, including Edinburgh, Bristol, and Oxford, as well as digital platforms maintained by the Wikimedia Foundation.

Illustration of darkened office monitors showing scheduled maintenance screens.
Illustration: Public agencies chose temporary website downtime over active exposure to automated scanning.AI-generated illustration

Security agencies issued stark directives as the bug became public. The US National Security Agency advised operators to pull systems offline if immediate patching was not possible, warning that the flaw provides a direct route into server file systems and databases. Britain's National Cyber Security Centre echoed the guidance, warning administrators to audit server logs for backdoors installed prior to remediation.

Technical Details of the Critical PHP Vulnerabilities

The PHP security team issued coordinated fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The maintainers warned that only PHP 8.2 and newer branches receive official security support, though minimal source-level backports were prepared for PHP 7.4, 8.0, and 8.1 to assist operators compiling from source or running older platforms.

Both vulnerabilities carry a CVSS v4.0 severity rating of 9.2:

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Remote code execution via out-of-memory (OOM) corruption. When memory allocation fails, out-of-memory handling can interrupt PHP while internal request structures are partially initialized. Subsequent cleanup steps mistakenly treat the uninitialized data as valid.
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Remote code execution via stale global state. Request-owned internal state can persist after its underlying memory has been freed. A subsequent request processed by the same worker process can then execute using the stale state before normal initialization resets it.

Maintainers noted that the risk is highest for Apache servers running mod_php, where unauthenticated requests can trigger memory corruption before any application code executes. As WIRED reported, the underlying weaknesses affect all web-facing PHP installations dating back to the release of PHP 5 in July 2004.

Discovery, Leaks, and an Accelerated Release Timeline

OpenAI claimed frontier AI had been key to uncovering the vulnerabilities, though the researcher who found the weakness stated they did not use models unavailable to the general public. A detailed timeline shared on Simon Willison's Weblog shows that researchers at Wiz first identified the flaw on August 19, 2026, using Wiz Atlas alongside Gemini 4 Argon and GPT-5.6 Sol. Wiz confirmed unauthenticated remote code execution against Drupal on August 20 and WordPress on August 21, submitting its findings to the PHP security team on August 24.

Simultaneously, security firm Calif identified the vulnerability using GPT-5.6 Sol as part of an initiative coordinated by OpenAI. The PHP project acknowledged the reports on September 21, working alongside security providers such as Cloudflare to validate patches and prepare web application firewall protections.

Illustration of a software researcher reviewing code architecture on multiple monitors.
Illustration: The PHP security team provided backports, while security researchers assisted with coordination and testing.AI-generated illustration

The planned disclosure was set for October 22, 2026. However, on October 20, the CVE identifiers leaked across public forums. Following the leak, Calif inadvertently published a video demonstrating its proof of concept, which was quickly captured and mirrored across social media, while Wiz researchers dubbed their demonstration "php2shell". The incident forced the PHP Foundation to move the release forward to October 21 at 14:00 UTC. To assist defenders, OpenAI published an open-source detection utility on GitHub allowing operators to inspect server headers and local binaries for vulnerable versions.

Mitigation Options and Next Steps for Defenders

The PHP Foundation stressed that applying the official updates remains the only comprehensive fix. For administrators facing maintenance windows where an immediate upgrade is impossible, the PHP team provided temporary configuration workarounds to reduce exposure to known exploit paths.

For CVE-2026-109618, operators can set memory_limit=-1 in server-level configurations (such as FPM pools or Apache directives) to disable controllable PHP memory limits, lower post_max_size to 8M or 32M, and enforce strict request limits at reverse proxies. For CVE-2026-109619, administrators must set session.upload_progress.enabled=0 and restart worker processes, as well as set fatal_error_backtraces=0 on PHP 8.5 installations.

Cloudflare reported seeing early exploit attempts immediately surrounding disclosure, though agencies in Belgium, Finland, and Australia reported no confirmed local breaches during initial triage. With millions of servers worldwide relying on PHP, security teams now face an extended remediation cycle to identify forgotten legacy installations before automated exploit tools achieve widespread coverage.

Questions people ask

Which versions of PHP are vulnerable to these flaws?

The vulnerabilities affect all PHP installations serving web requests dating back to PHP version 5.0 from July 2004. Official patches are available for supported releases: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

Why did organizations take websites offline instead of patching in place?

Because the vulnerabilities allow unauthenticated attackers to execute code remotely, European cybersecurity agencies advised operators to pull servers offline if they could not immediately test and apply the updates, minimizing exposure to automated exploitation.

Can web application firewalls or configuration changes fully prevent exploitation?

No. The PHP Foundation stated that there are no complete mitigations other than updating the PHP runtime. Configuration tweaks and firewall rules only reduce exposure to specific known trigger conditions.

Sources

  1. Patch the Planet: global response coordination as agents uncover critical vulnerabilitiesOpenAI, official source
  2. openai/php2shell-checkerGitHub, Oct 21, 2026, official source
  3. Flaw in PHP computer language leads to shutdown of websites around worldThe Guardian, Oct 21, 2026
  4. European governments pull websites offline over two critical PHP flawsTNW | Data-security, Oct 21, 2026
  5. ‘This Is Not a Drill’: Critical PHP Vulnerabilities Are Setting the Internet on FireWIRED, Oct 21, 2026
  6. Today’s PHP Security Release, and How We’re Strengthening PHP SecuritySimon Willison’s Weblog
  7. PHP: News Archive - 2026php.net, Oct 21, 2026

How this story was made: the newsroom picked it up from Google News, Techmeme and Hacker News, gathered the full text of the sources above, and drafted it with AI assistance. Every factual claim was then checked against those sources before publishing (34 claims checked). Illustrations marked as AI-generated are not photographs. Spotted an error? Tell us.

#PHP #Cybersecurity #Vulnerabilities #Web Security #Open Source

Published October 22, 2026 at 00:08 UTC