PHP has released fixes for two critical runtime vulnerabilities that can let unauthenticated attackers execute code with a web worker’s privileges. The October 21 advisories identify patched releases 8.2.35, 8.3.36, 8.4.27, and 8.5.12. One flaw concerns how the runtime exits when memory runs out; the other concerns request-owned state that survives in a reusable worker. Their shared consequence is serious, but their triggering paths and evidence of exploitability are not interchangeable.
The out-of-memory advisory, CVE-2026-109618, describes an error-handling problem rather than a simple failure to cap request size. PHP uses longjmp() to leave the current execution context after an out-of-memory error. Some contexts temporarily expose request memory before initialization is complete. An allocation failure at that moment can take an early-exit path that leaves this memory invalid; shutdown code may subsequently read it or branch on it. The failed allocation need not be directly connected to the invalid memory.
That distinction explains why apparently sensible input limits do not fully describe the attack surface. The advisory identifies multipart parsing paths that consume more memory than their wire size suggests, including unrestricted numbers of part headers and empty file controls that still allocate metadata. Nested field names can multiply array work. Requests without a usable declared content length can also pass an initial size check while continuing to supply decoded data. These are examples of how a request can drive allocation behavior, not evidence that every large upload is an exploit.
The patch changes the failure mechanism. Instead of using longjmp() for out-of-memory handling, PHP introduces a delayed, graceful soft failure at the next virtual-machine safe point and an immediate hard exit using _exit() at a second, higher memory threshold. According to the maintainers, this prevents shutdown from consuming invalid intermediate state while preserving the runtime’s ability to limit memory consumption. The engineering issue is where execution may safely stop, not merely how many bytes a process may allocate.
Deployment details matter. For the out-of-memory flaw, Apache mod_php always invokes request shutdown even when startup fails; automatic body parsing can therefore reach the dangerous path before application code runs. FPM exits a child after startup failure, blocking that particular consumption path. The advisory nevertheless identifies application-specific post-startup exposure in FPM based on source analysis, while explicitly saying a complete FPM exploit has not been demonstrated for this flaw. It describes FrankenPHP as likely susceptible to application-independent attacks and LSAPI’s application-specific exposure as likely but unvalidated. Those distinctions should survive any shorthand warning that PHP is affected.
The stale-global-state advisory, CVE-2026-109619, addresses a separate lifecycle boundary. Reusable workers retain global error, session, object, and extension state, some of which points into memory owned by one request. That state must be reset before the request memory is released. Certain input, configuration, session, and error-handling operations run before the next request’s normal initialization. They can consume stale pointers before initialization replaces them, creating a use-after-free.
A use-after-free is not simply leftover application data: the runtime acts on memory whose original ownership has ended and whose contents may have changed. The maintainers report that a strategically arranged heap can turn the flaw into remote code execution. Their validated cases include a fatal-backtrace path against mod_php and session-lifecycle attacks against both mod_php and FPM. This is stronger FPM exploit evidence than the out-of-memory advisory supplies. They also caution that other state families establish a security impact only after a concrete producer and consumer are shown.
Both advisories rate the issues critical at CVSS 4.0 score 9.2 and identify patching as the complete or reliable mitigation. The out-of-memory report discusses administrative configuration measures for installations that cannot immediately update, but those are not equivalent to fixing both vulnerabilities. In particular, removing a per-request memory limit changes a resource-control boundary and is not a blanket safe setting to copy into production. The stale-state report explicitly says the complete state-reset patch is the only reliable mitigation and directs operators to the related advisory as well.
For engineering teams, remediation begins with the PHP runtime actually serving traffic: identify its branch, hosting integration, and deployed build, then obtain the corresponding fixed release or a vendor-confirmed backport. Updating a content-management system or framework alone does not establish that its underlying interpreter changed. Rebuild affected images or packages as needed and replace running workers so the patched binary serves new requests. Verify vendor status for managed hosting rather than assuming the hosting model eliminates exposure. The practical lesson is that request isolation depends on safe initialization, teardown, and error paths inside the runtime—not only on validation in application code.
