Summary
PHP’s maintainers have fixed a critical out-of-memory flaw that the project says can allow unauthenticated remote code execution. The patch is available in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
PHP’s maintainers have patched a critical out-of-memory vulnerability that can allow an unauthenticated attacker to execute code remotely as a web worker. The project’s security advisory, CVE-2026-109618, rates the flaw 9.2 out of 10 under CVSS 4.0. It reports a complete HTTP exploit against Apache mod_php under the tested configuration.
The affected versions are those below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 in their respective release branches. Those four releases contain the fix.
How an out-of-memory error could become code execution
PHP uses longjmp() to leave the current execution context when it runs out of memory. The advisory describes a problem that can occur when a request is still being set up: some request memory is reachable before it has been fully initialized. If an allocation fails at that point, PHP can exit without accounting for the early exit. Later, the request shutdown procedure may read or make decisions using the invalid state. The allocation that fails does not have to be the one that caused the state to become invalid.
Certain multipart form-data requests can cause memory exhaustion while remaining within apparent PHP input limits. The advisory describes, among other paths, multipart parts with many headers and empty file controls that create metadata despite not counting toward the configured maximum number of file uploads. Application-specific inputs can also cause sufficiently large or repeated allocations.
For Apache mod_php, the request shutdown procedure runs even when request startup has failed. The advisory says the vulnerable sequence can therefore happen before application code begins. Its confirmed exploit achieved unauthenticated remote code execution as the web worker account over HTTP, using default PHP input and memory limits and normal prefork configurations with multiple workers. The advisory assigns the attack no required privileges and no user interaction, while rating its attack complexity high.
Fixed releases and mitigation
The patch removes longjmp() for out-of-memory handling. It introduces a delayed, graceful soft out-of-memory response at the next virtual-machine safe point, and an immediate hard out-of-memory exit if memory use reaches a second, higher threshold. The aim is to avoid running request shutdown over invalid state while retaining PHP’s normal ability to limit memory use.
The PHP project identifies upgrading to a release containing the patch as the only complete mitigation. For installations that cannot update, it names administratively setting and enforcing memory_limit=-1 as the primary configuration mitigation. That removes the predictable per-request limit used in the confirmed exploit, but is not complete protection: an underlying allocation failure can still reach the vulnerable path. The advisory also recommends limiting and validating decoded request sizes at the frontend, reducing input nesting and bounding multipart parts, headers and uploads. These measures reduce risk but do not replace upgrading.