PHP Group PHP: out-of-memory request-state corruption enables remote code execution

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

• PHP Group php-src, PHP 8.2.* branch: affected when the version is less than 8.2.35; fixed in 8.2.35.
• PHP Group php-src, PHP 8.3.* branch: affected when the version is less than 8.3.36; fixed in 8.3.36.
• PHP Group php-src, PHP 8.4.* branch: affected when the version is less than 8.4.27; fixed in 8.4.27.
• PHP Group php-src, PHP 8.5.* branch: affected when the version is less than 8.5.12; fixed in 8.5.12.

These boundaries apply to the branches listed in the affected-product record. The record does not provide complete upstream affected or fixed boundaries for other branches, so the status of PHP bundled by a distribution or another product must be verified against the relevant vendor advisory and package.

PHP uses longjmp() to exit the current context when an out-of-memory error occurs. In some contexts, request memory is reachable before it is fully initialized; if an allocation fails at that point, the early exit does not fully update internal state and leaves the request in an invalid condition. The subsequent request cleanup procedure may read or branch on that invalid memory, creating a use-after-free or uninitialized-pointer access condition.

1. Attacker-controlled input can drive PHP into an OOM condition while the request is being processed, particularly during multipart parsing.
2. The advisory identifies a multipart request without a usable Content-Length, an unrestricted number of headers in a part, empty file controls that do not count toward max_file_uploads, and nested field names that multiply the generated array work as relevant OOM strategies.
3. When request startup fails under Apache mod_php, request shutdown is still invoked before application code runs, allowing the invalid state to be processed inside the PHP core.
4. FPM removes a child when request startup fails, but OOM may still be reached after startup through paths that do not account for the early exit. The advisory supports FPM susceptibility through source analysis, but no complete exploit has been demonstrated for that SAPI.

The patch changes OOM handling by removing longjmp() from this path and delaying soft OOM until a VM safe point, while using a hard OOM at a higher threshold. The evidence does not fully establish every allocator layout or deployment condition needed for reliable exploitation.

The vulnerability is remotely reachable over HTTP without authentication or user interaction. The PHP advisory confirms complete remote code execution against Apache mod_php with default input and memory limits in a prefork configuration; processing can occur before application code begins execution.

• Exploit reliability depends on the PHP build, extensions, frontend behavior, allocator layout and worker population.
• For PHP-FPM, child termination when OOM occurs during request startup blocks one specific path, but post-startup OOM paths may remain. A complete FPM exploit has not been demonstrated in the advisory.
• FrankenPHP is assessed as likely susceptible in a manner analogous to mod_php; LSAPI is assessed as potentially susceptible through application-specific conditions but remains unvalidated.
• The available evidence confirms HTTP exploitation validation, but does not identify a specific victim, campaign or breach.

The confirmed technical outcome is unauthenticated remote code execution with the privileges of the web worker. With Apache mod_php, PHP may process invalid request state during request shutdown before application code executes, making the exposure independent of application logic.

• An attacker may affect the confidentiality, integrity and availability of data and services accessible to the worker.
• OOM during input processing may also cause request failures, worker termination or service disruption.
• FPM behaves differently when request startup fails, and no complete exploit has been demonstrated for that SAPI, but the advisory still considers FPM potentially affected by post-startup OOM paths.
• Exploitation does not by itself establish higher operating-system privileges, access to other systems or impact to processes outside the worker scope.

Successful exploitation can provide code execution with the privileges of the web worker, potentially allowing an attacker to read data available to that worker, alter application content or configuration, and disrupt service.

• With mod_php, the confirmed path occurs before application code runs, so reviewing individual application endpoints does not remove the risk.
• Requests that force OOM may also increase request failures, cause worker loss or reduce availability, depending on the SAPI and deployment model.
• The post-exploitation privilege boundary is the web worker account. The available evidence does not establish automatic operating-system privilege escalation or movement to other systems.

1. Upgrade each affected PHP branch to its corresponding fixed release: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. For PHP bundled by a distribution, appliance, container image or another product, install the vendor-provided backported package rather than updating only the host PHP installation.
2. Restart all PHP workers after updating and verify that no pool, directory or application setting restores the vulnerable configuration.
3. If immediate updating is not possible, PHP identifies administratively enforced memory_limit=-1 as the primary configuration mitigation because it removes the per-request limit that enables a predictable controlled OOM. This is temporary and incomplete, and it can allow a request to consume all available memory.
4. Keep post_max_size conservative, independently enforce decoded request size at the frontend, reduce max_input_nesting_level, and limit input variables, multipart parts, headers within each part and uploads. If the application does not use multipart form data, block those requests before they reach PHP.
5. Do not use RLIMIT_AS or RLIMIT_DATA as substitute mitigations, because allocation failure through mmap() can trigger the vulnerable longjmp() path. A container or cgroup limit such as memory.max may help in some deployments, but it is not a complete mitigation.

1. Inventory every PHP runtime that serves requests, including PHP through Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LSAPI, and runtimes bundled in appliances, containers or images.
2. Check the effective binary, package and image version, then compare it with each affected and fixed branch. Do not infer that a branch is safe merely because it is absent from the inventory.
3. Review effective settings related to OOM and multipart handling, including memory_limit, post_max_size, max_input_vars, max_input_nesting_level, upload limits, and frontend limits on multipart parts and per-part headers.
4. Review web server, PHP and process supervisor logs for OOM-related request failures, request-startup failures, worker exits or worker replacement. Treat this as precautionary monitoring, not as a confirmed indicator of compromise.
5. Verify the package source or vendor advisory for every product that embeds PHP to confirm that the fix was backported. The absence of matching log events does not demonstrate that a system is unaffected.