European government sites go dark after critical PHP flaws force emergency response

A pair of critical security flaws in the PHP programming language forced government websites offline across Europe on 21 October. According to Reuters, authorities in the Netherlands and Finland took precautionary action by disabling their public-facing sites to guard against potential exploitation. PHP, a server-side language powering countless websites and applications built on WordPress, Drupal and Joomla, became the focus of an emergency security response.

Both vulnerabilities received a CVSS severity rating of 9.2 out of 10, indicating they could permit attackers without valid credentials to inject and run harmful code on vulnerable servers. The PHP development team released emergency patches on 21 October and called on all organisations to deploy them without delay.

Critical PHP Vulnerabilities Allow Remote Code Execution

The two flaws, designated CVE-2026-109618 and CVE-2026-109619, stem from how PHP handles memory during request processing. CVE-2026-109618 relates to PHP's management of out-of-memory conditions. When triggered, partially set-up data might be wrongly accepted as legitimate, creating an opening for remote code execution by an attacker.

CVE-2026-109619 involves PHP keeping data from an earlier request even after the memory holding it was freed. This flaw could enable attackers to view confidential data or run code with the privileges of the web server process.

Huntress, a cybersecurity firm, noted in its technical review that these flaws could be weaponised without authentication in certain setups, particularly Apache installations running mod_php.

The PHP team issued four corrected releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older no longer get direct security fixes from the PHP project, though some operating system vendors and extended-support providers may issue their own patches.

Government Websites Taken Offline as Precaution

Dutch authorities announced on 21 October that multiple government service portals had been shut down temporarily as a safeguard. The affected sites included Overheid.nl, MijnOverheid.nl and DigiD. The Netherlands' National Cyber Security Centre (NCSC-NL) also took its own website offline while addressing the flaws.

The NCSC-NL advised website operators to evaluate their vulnerability and weigh whether temporary shutdowns were necessary if risks could not be sufficiently reduced. Finnish government agencies similarly implemented precautionary steps, according to Reuters.

Following the vulnerability announcement, some reports suggested possible exploitation attempts. However, Huntress stated it had not detected active attacks leveraging these flaws in its monitored systems, though it acknowledged reports from other security researchers. The Dutch NCSC likewise reported no signs of active exploitation at the time it made its statement. The temporary shutdowns therefore did not confirm that the government websites had actually been breached.

Security Experts Warn of Patching Risks

Matt Saunders, DevOps Lead at The Adaptavist Group, explained that the danger of attackers exploiting newly revealed flaws shaped the choice to shut down services. "Many organisations now consider the risk of a security breach to outweigh the reputational and organisational damage of an outage. Pre-emptively taking services down to protect and then patch them is a pragmatic choice."

Saunders also cautioned that AI-powered attacks might speed up efforts to exploit newly disclosed flaws, though evidence of AI involvement in attacks targeting these specific vulnerabilities had not surfaced.

Martin Riley, Chief Technology Officer at Bridewell, pushed back against the notion that all PHP-based websites face equal danger. "Being built on PHP does not automatically mean a site is exploitable. The specific affected versions and configurations will determine that," Riley stated.

Riley stressed that site operators must identify where PHP runs across their systems, including within third-party tools and hosted services. "WordPress automatic updates will not fix the underlying PHP runtime," he cautioned, highlighting that organisations must ensure patches reach the PHP installation itself rather than relying solely on content management system updates.

Emergency Patches Raise Service Disruption Risks

Deploying urgent security fixes carries its own operational hazards, as changes may affect other system components. Jamie Beckland, Chief Product Officer at APIContext, warned that organisations might face additional downtime following patch installation.

"A security patch deployed under enormous pressure can trigger a chain reaction across interconnected systems. Websites may initially appear healthy while customers find themselves unable to log in, make payments, or complete transactions," Beckland said. He noted that automated checks might overlook problems affecting actual customer workflows, even when infrastructure monitoring shows normal operation.

"The real test comes after the emergency fix, when teams have to make sure every critical customer journey still works."

With patches now available, operators must locate vulnerable PHP instances, roll out updates and verify that core functions remain intact. Organisations using outdated software or depending on external vendors to manage infrastructure face longer remediation timelines, potentially leaving gaps in protection once the initial crisis response ends.