PHP2Shell: Even the Cybersecurity Agency Took Its Website Offline

Two critical PHP vulnerabilities put servers and sensitive data at risk, regardless of which CMS was running.

On Wednesday, October 21, 2026, government websites in five European countries were taken offline following warnings about two critical security vulnerabilities in PHP.

The Netherlands temporarily disabled Overheid.nl, MijnOverheid.nl and DigiD, its government digital identity service.

The Dutch National Cyber Security Centre (NCSC) also took its own website offline.

France shut down prefecture websites.

Germany's federal IT provider, ITZBund, disabled several government sites.

Belgium's foreign ministry took its websites offline, while Finland's state IT centre, Valtori, shut down public government web services.

Austria also saw precautionary shutdowns. The University of Vienna, TU Wien, Caritas Austria and regional newspaper NÖN temporarily took websites offline.

The disruption extended beyond government.

The Port of Rotterdam, Dutch political parties, hospitals and several Wikimedia services were also affected by precautionary shutdowns.

Even the organisation responsible for warning Dutch institutions about the vulnerability had to temporarily remove its own website from the internet.

The Bug Doesn't Care Which CMS You Use

PHP2Shell refers to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on the CVSS v4.0 scale. They affect PHP itself.

Guys at Wiz demonstrated remote code execution without authentication against WordPress, Drupal and Joomla installations. An attacker can send specially crafted requests and execute code on the server. No stolen administrator password is required.

The vulnerabilities involve how PHP handles memory during errors and subsequent requests. In some configurations, exploitation can occur before the website's own application code runs.

The Data Was Part of the Problem

A compromised server can be used for cryptocurrency mining, spam or further attacks. Those are established consequences of remote code execution, but they aren't the most important aspect of PHP2Shell.

The problem was the ability to read sensitive PHP process memory without first achieving full remote code execution.

That memory can contain passwords, authentication tokens, API keys and other information processed by a website.

With remote code execution, an attacker may also access application files, source code, database credentials and any databases or services available to the compromised process.

The extent of that access depends on the server's configuration, permissions and network isolation. Older applications with excessive privileges or weak separation between services could expose considerably more.

A municipal website might handle little beyond opening hours and rubbish collection schedules. Another government portal might process identity information, applications or personal records.

Government procurement can deliver a functioning website without providing the expertise needed to maintain it securely. Sensitive citizen records should be stored separately from public website data, protected by network isolation, restricted database permissions and tightly controlled access.

A public-facing PHP server has no business having unrestricted access to an entire citizen database.

These measures would not have prevented PHP2Shell, but they could have significantly limited what an attacker could steal after exploiting it.

Fourteen Years of Vulnerable PHP

According to Wiz, affected code goes back at least to PHP 5.4, released in 2012.

The PHP Foundation has now acknowledged that signs of the underlying memory-management problem were discovered during security work in 2024.

But, proposed fixes raised compatibility and stability concerns, and work stalled.

In August 2026, people demonstrated working attacks and reported them to PHP's security team. A coordinated fix was prepared for October 22.

Details leaked on October 20, prompting the PHP team to bring the release forward to October 21.

Cloudflare soon reported malicious traffic targeting its customers and attempts to modify attack requests to evade protections.

What You Need to Fix

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21 to address both vulnerabilities.

Websites running older, unsupported PHP releases need upgrades or appropriate vendor-supplied security backports.

Updating WordPress, Drupal or a custom CMS does not replace updating the PHP runtime.

Web application firewalls can reduce exposure, and Cloudflare deployed protective rules before public disclosure. Those rules are additional protection, not a fix.

Administrators need to examine logs and evidence of compromise. Installing a patch does not reverse earlier unauthorised access or invalidate credentials that may already have been exposed.

CERT-EU advised organisations unable to patch immediately to consider isolating affected internet-facing applications.

That explains Wednesday's government website outages.

Taking a government portal offline is inconvenient.

Leaving a vulnerable server connected to sensitive records can be considerably more expensive.

The Dutch cybersecurity agency evidently considered a temporary outage the preferable option.

For once, a government website displaying an unavailable-service message was doing exactly what its administrators intended.

The immediate problem may be resolved by patching PHP, but the consequences of any successful breaches could take much longer to emerge. Stolen personal information could be used to create false identities, submit fraudulent applications or gain access to other government services. Attackers with sufficient permissions could also have altered official records.

This raises questions about the growing dependence on digital identity systems. Making a single digital ID the gateway to an increasing number of government services concentrates this risk.

We will be observing the fallout for the next couple of weeks.