Remote Code Execution (RCE) Affecting php package, versions [,8.2.35)[8.3.0,8.3.36)[8.4.0,8.4.27)[8.5.0,8.5.12)


Severity

Recommended
0.0
critical
0
10

CVSS assessment by Snyk's Security Team. Learn more

Threat Intelligence

Social Trends
Exploit Maturity
Proof of Concept
EPSS
11.62% (97th percentile)

Do your applications use this vulnerable package?

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 applications
  • Snyk IDSNYK-UNMANAGED-PHP-21347795
  • published21 Oct 2026
  • disclosed20 Oct 2026
  • creditlcfr-hax, sagitzadik-wiz, tomash-areion, amyb-oai

Introduced: 20 Oct 2026

NewCVE-2026-109618  (opens in a new tab)
CWE-94  (opens in a new tab)

How to fix?

Upgrade php to version 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher.

Overview

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.

Workarounds

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.

CVSS Base Scores

version 4.0
version 3.1