Act nowDisclosed

Advisory · CVE-2026-109618

PHP out-of-memory handling can leave request memory uninitialized and give remote code execution

PHP before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 uses longjmp for out-of-memory errors in contexts that can leave request memory uninitialized, so request cleanup can read or branch on that memory and multiple out-of-memory strategies can give unauthenticated remote code execution. CVSS 3.1 9.8.

Advisory published October 21, 2026Independent summary
Vendor
PHP Group
Product
PHP
Identifier / CWE
CVE-2026-109618
CWE-416
Action timing
Immediate
ELI5

Explain it like I’m five

When PHP runs out of memory mid-request it jumps out early, and in some paths that jump skips the setup of memory the cleanup code later trusts, so a crafted request that forces the memory limit can steer the worker into running attacker code.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Crafted request sent

    An unauthenticated attacker sends requests, including multipart requests, designed to exhaust the PHP memory limit during request handling.

  2. 02Out-of-memory jump taken

    PHP uses longjmp to abort the current context on the out-of-memory error, as the project advisory describes.

  3. 03Request memory left invalid

    In the affected contexts the early exit leaves request memory in an uninitialized or invalid state before a later allocation.

  4. 04Cleanup reads invalid state

    The request shutdown and cleanup procedure reads or branches on that invalid memory.

  5. 05Code runs as the web worker

    Per the project advisory, multiple out-of-memory strategies can consistently trigger this condition and lead to remote code execution, confirmed against Apache mod_php.

What happened

The PHP project disclosed CVE-2026-109618: PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request, but some contexts do 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. The project advisory states that multiple OOM strategies can consistently trigger this condition and lead to remote code execution, with complete RCE validated over HTTP against Apache mod_php with default PHP input and memory limits; source analysis also supports FPM as susceptible, though no complete FPM exploit has been demonstrated for this issue. The CVSS 3.1 score is 9.8, with network attack vector, low complexity, no privileges, and no user interaction.

Per the affected data in the NVD record, the 8.2 line before 8.2.35, the 8.3 line before 8.3.36, the 8.4 line before 8.4.27 and the 8.5 line before 8.5.12 are affected, so upgrading to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later for your line is the stated fix. The project advisory says updating is the only complete mitigation; it also cross-references the related stale global state issue tracked as CVE-2026-109619, so apply the same release for both. The advisory notes setting memory_limit to -1 administratively is only a partial configuration mitigation, not a complete one.

What to do

  1. Inventory PHP runtimes behind web servers and application servers, including mod_php, FPM, FrankenPHP and LSAPI deployments, and note the version and branch of each.
  2. Upgrade affected installations to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later for the branch in use, using the project release guidance.
  3. Until every worker is updated, keep PHP memory limits and request size controls conservative, enforce decoded request size at the frontend, and block multipart requests at the frontend for applications that do not use them, per the project advisory.
  4. Do not rely on memory_limit set to -1 as a fix; the advisory describes it as a partial mitigation only, and workers must be restarted after any such change.
  5. Hunt for repeated multipart requests, requests with very many part headers or empty file controls, workers hitting the memory limit, and web worker processes spawning unexpected commands.
  6. Verify the deployed version on every worker after updating, including workers behind load balancers and in container images.

Management note

PHP runs a large share of the public web, and this is an unauthenticated path to code execution as the web worker that fires before application code in the confirmed mod_php case. Patch PHP on the emergency ring and treat any long-running unpatched internet-facing worker as exposed.