Two critical vulnerabilities in PHP have prompted government agencies across Europe to temporarily shut down websites, as administrators rush to protect vulnerable servers from potential cyberattacks.
The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, could allow attackers to execute malicious code on affected servers without login credentials. Both carry severity scores of 9.2 under CVSS v4.0, according to Google Cloud’s security analysis.
Emergency patches were released on Oct. 21, giving organizations a way to address the vulnerabilities. However, the precautionary shutdowns show how security flaws in widely used software can disrupt essential services even without a confirmed breach.
Government websites go offline amid PHP security concerns
Government agencies in the Netherlands, Germany, France, Belgium, and Finland temporarily suspended access to websites on Oct. 21 as a precaution against the PHP vulnerabilities.
According to Reuters, the disruption also affected websites operated by schools, hospitals, and other organizations across Europe.
The Dutch government confirmed that services including Overheid.nl, MijnOverheid.nl, and DigiD were temporarily taken offline. Officials said there were no indications of active exploitation at the time.
Germany’s federal IT service provider also suspended several websites, while France temporarily took prefecture websites offline. Finland’s state IT center shut down public web services as a precaution.
The European Union’s cybersecurity response team, CERT-EU, had advised organizations unable to patch immediately to consider isolating vulnerable internet-facing applications.
The outages were preventive measures, not evidence that the affected government systems had been breached.
How the two PHP vulnerabilities work
The flaws affect PHP, a programming language used to power websites, content management systems, and business applications.
According to the PHP project’s security advisory, both vulnerabilities could allow unauthenticated remote code execution under certain conditions.
- CVE-2026-109618: An out-of-memory handling flaw can cause PHP to process partially initialized internal data, potentially resulting in memory corruption.
- CVE-2026-109619: An error-handling flaw can leave references to freed memory, allowing later requests to interact with stale internal state.
Researchers demonstrated remote code execution involving Apache with mod_php. The PHP project considers that deployment particularly exposed because a malicious request may trigger exploitation before application code runs.
Other configurations, including PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed, may also be affected.
However, exploitability depends on the PHP version, server configuration, and attack conditions. Not every PHP-powered website faces the same level of exposure.
Which PHP versions need updating?
Google Cloud reported that PHP versions 5.4 through 8.5.11 are affected. The PHP development team released the following fixes on Oct. 21:
| PHP branch | Fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
The PHP project strongly recommends updating immediately.
Organizations running PHP 8.1 or earlier should check whether their operating system or long-term-support vendor provides backported fixes. The PHP project no longer maintains those branches through its regular security release process, although it has provided limited source backports for some older versions.
Temporary configuration changes may reduce exposure to certain attack paths, but they are not complete substitutes for security updates.
Why businesses should check their PHP applications
The vulnerabilities affect the PHP runtime itself rather than a particular website or plugin.
That means a business could have an up-to-date customer portal, content management system, or internal application while still running a vulnerable version of PHP underneath it.
Cloud deployments can introduce additional complications because responsibility for updating the runtime depends on the service.
Google Cloud said its underlying infrastructure is not vulnerable, but customers running PHP applications may still need to take action.
Supported PHP runtimes on App Engine Standard receive automatic updates. However, organizations using custom runtimes, certain Cloud Run deployments, or Google Kubernetes Engine may need to rebuild and redeploy their workloads with patched PHP versions.
Businesses using third-party hosting or managed applications should confirm whether their providers have deployed the necessary fixes.
What IT teams should do now
Organizations running PHP should prioritize these actions:
- Identify affected installations. Check PHP versions across websites, business applications, containers, and third-party products.
- Deploy the patches. Upgrade supported installations to the appropriate fixed version or apply a verified vendor-provided update.
- Prioritize internet-facing services. Focus first on exposed systems, particularly Apache deployments using mod_php.
- Verify cloud workloads. Confirm whether updates are automatic or require rebuilding and redeployment.
- Review logs and restore services safely. Investigate suspicious activity and verify remediation before bringing precautionarily suspended services back online.
Where immediate patching is not possible, organizations should evaluate temporary isolation or service restrictions based on the risk to their environment.
IT teams should also coordinate with hosting providers and software vendors to confirm that fixes have been applied across every affected system.
What the PHP security scare means for IT leaders
The PHP incident highlights two connected risks: vulnerable software can expose systems to attackers, while emergency security measures can interrupt services that businesses and the public depend on.
The government shutdowns demonstrate the operational trade-offs organizations face when a critical vulnerability affects widely deployed infrastructure.
For businesses, the immediate priority is applying the available patches. The broader challenge is maintaining visibility into the software components that support essential applications, especially when updates depend on external vendors or cloud providers.
A strong response requires more than knowing that a patch exists. IT teams need to identify affected systems quickly, understand who is responsible for updating them, and verify that services can be restored safely.
Those capabilities will matter long after the immediate PHP security emergency has passed.
Other news: The US Department of Homeland Security has ordered federal civilian agencies to remove DeepSeek technology from their IT systems and stop purchasing affected products.