This vulnerability is trending on Twitter; this may indicate a growing threat.
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade php to version 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher.
Affected versions of this package are vulnerable to Remote Code Execution (RCE) due to a use after free in the out-of-memory handling, which calls longjmp() to abandon the current context at the point an allocation fails, including contexts where request memory is reachable but only partially initialized, leaving it in an invalid state that the request shutdown procedure then reads or branches on. An attacker can reach remote code execution by driving a request to exhaust memory during body parsing, using a multipart request with no usable declared content length to keep supplying decoded data past the initial post_max_size check, an unbounded number of headers within a part whose in-memory representation costs far more than their wire form, or empty file controls that bypass max_file_uploads while still building the file metadata arrays. The failing allocation need not be related to the invalid memory, and application specific input that causes a large or repeated allocation reaches the same path.
Apache mod_php has the highest risk, because it invokes request shutdown unconditionally even when request startup has failed, so the whole sequence completes before any application code runs, and FrankenPHP calls shutdown unconditionally in the same way. FPM exits the child when request startup fails, which removes that application independent path and leaves only post-startup OOM, for which no complete exploit is demonstrated, and LSAPI follows the FPM model with exploitation likely but unvalidated.
The following partial mitigations are possible, but none completely remove the vulnerability.
Set memory_limit=-1 where applications cannot override it, via php_admin_value in the FPM pool or Apache config, and confirm no pool, directory, or application setting restores a finite limit. This removes the predictable per-request failure, not an underlying allocation failure.
Set post_max_size to 8M without file uploads or 32M with, keeping upload_max_filesize below it, and enforce frontend limits on decoded request size, input field count, multipart part count, header count, and nesting depth. Those frontend limits must also apply to requests carrying no usable Content-Length.
Use a container or cgroup limit as an availability boundary, with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA: they can themselves trigger the vulnerable allocation failure.