PHP security release · October 21, 2026

PHP fixes two critical request-lifecycle RCE flaws

The PHP project released fixes for CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution, but they arise from different request-lifecycle failures and have different reachability conditions.

💡 Plain English: two different request-handling failures

Think of a web worker as a clerk handling one request card after another. In CVE-2026-109618, an emergency exit interrupts filling the current card, but the cleanup clerk still reads fields that were never finished. In CVE-2026-109619, the clerk keeps a pointer to a card from the previous request after it was discarded; the next request can follow that stale pointer. Both involve request lifetime, but they are separate failures.

SAPI: The interface PHP uses to connect its runtime to a web server or process manager, such as mod_php or FPM.
Request-owned memory: Memory that PHP allocates for one request and releases when that request ends.
Persistent worker: A PHP process that stays alive and handles multiple requests in sequence.
OOM: Out of memory: an allocation cannot be satisfied.

Exposure depends on the SAPI and request path. The PHP project says all web-serving PHP installations should update, with the highest risk in mod_php. The first advisory demonstrates a pre-application-code path in mod_php; it describes FPM as susceptible by source analysis but says no complete FPM exploit was demonstrated for that flaw. Do not treat every SAPI as equally exploitable.

Affected versions and response

Issue	Failure boundary	Fixed upstream versions
CVE-2026-109618 · OOM corruption	An out-of-memory `longjmp()` can interrupt partially initialized request state; shutdown may then consume invalid state. Confirmed pre-application-code route is mod_php; FPM reachability differs.	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP also published minimal source backports for 8.1, 8.0, and 7.4.
CVE-2026-109619 · stale global state	A worker can retain a pointer to request-owned state after its memory is freed; a later request on that worker may consume it before normal initialization resets it. Reachability depends on the producer/consumer path and SAPI.	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Verify older-branch and distributor backports with the package vendor.

CVE-2026-109618: OOM interrupts request initialization

PHP uses `longjmp()` to leave some out-of-memory paths. The advisory describes contexts where request memory is reachable before initialization is complete. If allocation fails there, the nonlocal exit can skip state handling; later shutdown may read or branch on invalid request data. The PHP project documents several multipart parsing paths that can reach OOM and says mod_php invokes shutdown even after request startup fails. The upstream fix replaces this OOM `longjmp()` path with a delayed soft OOM at a VM safe point and a hard exit at a higher threshold.

CVE-2026-109619: request state survives into a later worker request

PHP workers retain some global fields between requests, while the memory they point to belongs to one request. A fatal interruption or a diagnostic during shutdown can leave or repopulate a stale reference; after that request heap is freed, a later request on the same worker may consume it before normal initialization. The advisory confirms early INI-diagnostic and session-upload-progress consumers. Its mod_php and conditional FPM paths differ; hiding warnings with `error_reporting`, `display_errors`, or `@` does not close the boundary. The upstream fix resets affected global state so it is no longer available to consumers that run before normal request initialization.

Separate PHP notice (CVE-2026-115560; October 23): PHP describes an unlikely RCE vector that requires all three conditions: session.serialize_handler is php_binary or php_serialize in configuration; application code changes it to php at runtime before session_start(); and session upload progress remains enabled. PHP recommends session.upload_progress.enabled=0 until a future regular bugfix release. The full advisory and fix are pending. This issue is separate from CVE-2026-109619, and the October 21 fixed versions should not be assumed to address it. Applications that never change the serializer at runtime can keep upload progress enabled. Read PHP's notice.

Defensive response

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install a vendor-confirmed backport; verify the runtime package and restart all PHP workers.
For CVE-2026-109618, use the PHP advisory's interim limits only as risk reduction. `memory_limit=-1` can remove a controllable per-request limit but is not complete protection; bound decoded request and multipart sizes at the frontend.
For CVE-2026-109619, set `session.upload_progress.enabled=0` in server or pool configuration and restart workers to block the confirmed session paths. On PHP 8.5, `fatal_error_backtraces=0` blocks only the confirmed backtrace path; neither workaround covers every variant.
Do not use `RLIMIT_AS` or `RLIMIT_DATA` as an OOM workaround; PHP warns these can cause the vulnerable allocation-failure path. Confirm all interim controls against the upstream advisories.

How the findings emerged

The PHP Foundation credits researchers at Calif, OpenAI, and Wiz with findings in the investigation behind this release that helped clarify root cause and impact. It also describes AI-assisted scanning and report validation as part of PHP’s broader security work, without attributing discovery of these two CVEs to a specific AI tool. PHP maintainers assessed reports and worked on the fixes. Read the Foundation’s account.

PHP security release advisory PHP advisory: CVE-2026-109618 PHP advisory: CVE-2026-109619 PHP notice: CVE-2026-115560 The PHP Foundation: release and security response ENISA joint statement Conceptual simulator: heap use after free Security directory

Advisory status checked October 25, 2026.