A critical PHP flaw is taking websites offline. Here is what needs fixing.
Emergency patches address two flaws that can let attackers run code without signing in. A working homepage is not proof that a server is protected.
A security flaw in one of the web’s most widely used programming languages has turned an ordinary software update into an emergency. PHP’s maintainers have released fixes for two critical vulnerabilities that can let an attacker run code on a server without first signing in.
The immediate question for a website owner is not whether the homepage still loads. It is whether the infrastructure serving that page runs an affected PHP version—and whether the organisation responsible for it has applied and verified the appropriate patch.
CERT-EU’s October 21 advisory lists the fixed releases as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Sites using earlier releases in those branches should treat the issue as urgent. A static HTML site does not become vulnerable merely because it is on the internet, but an apparently static front end can still depend on a PHP-powered service elsewhere.
Two flaws, one urgent response
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. CERT-EU gives both a severity score of 9.2. One involves memory corruption during out-of-memory handling; the other involves stale global state. Both can lead to unauthenticated remote code execution.
That is a substantially different problem from a malicious comment or a stolen account password. In a successful attack, the software processing a request could be manipulated before the website’s own application code has a chance to protect it. Normal account restrictions are therefore not a substitute for fixing the underlying runtime.
The advisory covers installations serving web requests through several common configurations, including PHP-FPM, Apache’s mod_php, CGI, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk configuration, not the only configuration at risk. Moving to another application framework without updating the PHP runtime would miss the central issue.
Why some services went offline
The disruption has included precautionary shutdowns rather than only confirmed intrusions. BBC reporting described affected public services in Finland, a Dutch government agency’s website and services connected with Edinburgh council among organisations taking protective action.
Those shutdowns should not be read as proof that every affected organisation was hacked. Taking a service offline can be a defensive decision while administrators assess exposure, install a patch or wait for a hosting provider. Conversely, a website remaining online does not demonstrate that it is safe.
Public proof-of-concept material raises the pressure on defenders. CERT-EU warns of the likelihood of attacks, making a leisurely maintenance cycle a poor fit for the risk. The useful distinction is between a verified fix and an assumption that an attacker has not noticed the server yet.
What a website owner should check
CERT-EU’s October 21 advisory identifies fixed upstream releases as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These are the fixes listed for this incident, not a promise that they will remain the newest releases. Administrators should check current PHP and distribution-vendor notices for their branch and deployment.
For a managed website, the fastest productive step is to ask the host or platform operator whether the relevant PHP runtime is patched. The version displayed in a control panel may not tell the entire story: operating-system vendors sometimes backport security fixes while retaining an older-looking version number.
That makes the vendor’s security notice important. Owners should seek confirmation for the actual service in use, including background endpoints and separate application servers, rather than treating an updated laptop or a changed theme as evidence that production is protected.
Older, end-of-life branches need particular care. The PHP security team has supplied minimal backports for some older versions, according to CERT-EU, but that is not the same as restoring their normal support lifecycle. A short-term emergency patch and a plan to move onto supported software solve different problems.
A patch is the priority—not a cosmetic change
CERT-EU recommends immediate patching and, where that is not possible, considering isolation of internet-facing services until a fix is installed and verified. Temporary workarounds may reduce exposure; they do not make an affected installation safe.
For readers trying to interpret the headlines, the clearest test is simple: identify the software, establish who maintains it, and obtain confirmation that the correct vendor fix is in place. Changing passwords, clearing a browser cache or redesigning the page does not repair a vulnerable server runtime.
