Critical PHP flaws trigger shutdowns as operators race to patch web infrastructure
Illustrative image: Brett Sayles on Pexels
Emergency patches for two critical PHP vulnerabilities have sent operators across web infrastructure into an accelerated update cycle, with some withdrawing services rather than leaving unpatched systems accessible. Both flaws can permit unauthenticated remote code execution and carry a CVSS v4.0 score of 9.2.
The UK’s National Cyber Security Centre has urged organisations to identify PHP installations across their infrastructure, prioritise internet facing systems and monitor for malicious activity. Its guidance includes considering an offline period where immediate remediation is not feasible. The Dutch NCSC confirmed that it temporarily took its own website offline as a precaution.
The shutdowns reflect the severity of the underlying defects and the difficulty of establishing exposure quickly. PHP can be installed directly, supplied through a hosting platform or embedded within a third party product. Patching responsibility follows those different delivery routes, which complicates an otherwise straightforward instruction to update.
Memory exhaustion exposes an unsafe cleanup path
CVE-2026-109618 concerns PHP’s handling of out of memory conditions. PHP uses longjmp() to abort processing when an allocation fails, but that exit can interrupt operations while internal request structures are only partially initialised. Subsequent shutdown processing can consume the invalid state.
The PHP security advisory describes confirmed remote code execution against Apache’s mod_php under normal prefork configurations and default PHP input and memory limits. In that configuration, the vulnerable sequence can occur during request startup, before application code executes. Authentication within the application therefore does not protect that path.
The fix changes the memory exhaustion mechanism. Rather than allowing an immediate jump out of an operation that cannot safely accommodate it, PHP introduces a delayed soft out of memory response at a virtual machine safe point, alongside a hard termination threshold. The change addresses the lifecycle failure while retaining memory consumption controls.
Request state survives its backing memory
CVE-2026-109619 involves request owned state retained by a persistent worker after the associated memory has been freed.
Error, session and other internal state must be cleared before request memory is released. The advisory identifies paths where fatal interruptions or later diagnostics leave references behind. Operations occurring before normal initialisation of a subsequent request can then consume that stale state.
Confirmed remote code execution includes paths involving mod_php and PHP-FPM, although the prerequisites differ. Exploitation depends on the producing and consuming requests reaching the same worker. Multiple workers and worker recycling can reduce the success rate per request without removing the vulnerability.
These deployment differences matter when assessing exposure. They do not support treating an entire server configuration as unaffected simply because it avoids one published exploit sequence.
Bundled runtimes complicate the response
The inventory problem extends beyond conventional website hosting. The NCSC explicitly includes appliances and services that bundle PHP in its advice to monitor third party vendor updates. CERT-EU likewise warns that commercial and open source products may be affected even where the operator does not directly expose or administer a PHP installation.
Within a hardware product, a web management interface can have a separate software stack and maintenance cycle from the firmware performing acquisition, control or communications. Whether that interface uses PHP requires confirmation from the software inventory or vendor; its presence cannot be inferred from the browser interface alone.
Updating such a runtime independently may also fall outside the vendor’s supported configuration. The response then depends on a release for that product, supported mitigation or explicit statement that the product is unaffected. A generic assurance that the operating system is current does not establish the status of an application’s bundled dependencies.
The distinction becomes particularly awkward where the equipment remains serviceable but its management software has reached the end of support. Hardware life and software maintenance commitments do not necessarily expire together.
A published patch still has to reach the running service
PHP’s fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and vendors providing long term support received patches ahead of disclosure, so vendor package advisories are relevant when assessing systems using backported fixes.
PHP’s maintainers state that updating is the only complete solution. Their temporary measures address specific attack paths and do not establish that an installation is safe.
CERT-EU recommends isolating affected internet facing applications where immediate patching is impractical, until the fix has been applied and verified. That verification is a separate operational step from downloading a package or scheduling an update.
The discovery also illustrates the changing pace of vulnerability research. OpenAI says Calif identified a critical flaw using its model through the Patch the Planet initiative, while Wiz independently discovered and reported both vulnerabilities. PHP’s maintainers led the fixes and release, with research and infrastructure partners supporting the coordinated response.
The immediate constraint is now deployment: establishing which products contain the affected runtime, obtaining supported fixes and confirming that vulnerable instances have been replaced. A precautionary shutdown can provide time to complete that work. Restoring service depends on closing the exposure, rather than simply clearing the maintenance page.
