CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
CVE-2026-109619: PHP RCE via stale global state
The PHP project’s description of CVE-2026-109619 is short and specific: request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it. It is rated critical, CVSS v4.0 9.2, the same score the project gives CVE-2026-109618.
Last updated
| Field | What the cited sources say |
|---|---|
| CVE | CVE-2026-109619 |
| GitHub advisory | GHSA-6wmf-4rv5-p3rp |
| Severity | Critical. CVSS v4.0 9.2. |
| Vector | The University of Toronto advisory assigns AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H to each of the two CVEs. We did not find that vector string in the php.net news text. |
| Fixed releases | The same packages as CVE-2026-109618: 8.2.35, 8.3.36, 8.4.27, 8.5.12. |
| Weakness label | Use-after-free is the term used by the PHP Foundation, the University of Toronto advisory, and the Canadian Cyber Centre (CWE-416). php.net’s headline phrase is “RCE via stale global state.” |
What goes wrong, at the level the vendor published
The PHP Foundation says a fatal error at the wrong point can leave internal state pointing at memory that belonged to a previous request. A later request on the same worker can then use that freed memory. The Foundation says a use-after-free and a worker crash were confirmed, and that the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php. The UK NCSC’s description matches the php.net sentence: state survives after its backing memory is freed, and a later request on the same worker may use it before initialization resets it.
The University of Toronto advisory names session upload progress, which is enabled by default, as one confirmed path. The PHP project’s interim guidance says setting session.upload_progress.enabled=0 blocks the confirmed session paths and does not block other variants. Disabling that setting is a mitigation, not a fix. We are not describing how a request reaches the fatal-error window.
mod_php and PHP-FPM
Expel, attributing the result to PHP, says PHP demonstrated this CVE against PHP-FPM in a case where the application’s own code can be pushed into a fatal error. FPM exposure depends on the application and the setup, and PHP still considers FPM installations at risk. mod_php remains the configuration the PHP project calls highest risk, including for this pair of bugs as a whole. The Canadian Cyber Centre repeats that assessment: a demonstrated exploit on mod_php allows an unauthenticated request to trigger the vulnerability before application-level code runs.
Fix
There is no separate patch. Install the 21 October releases and restart every worker. On PHP 8.5 the project also lists fatal_error_backtraces=0 as an interim measure that blocks only the confirmed fatal-backtrace path. Hiding diagnostics with error_reporting, display_errors, or the @ operator does not help, according to the php.net advisory. Google Cloud lists vulnerable versions as 5.4 through 8.5.11 for the pair; see the version page for how that sits next to the branches PHP actually shipped fixes for.
Sources
Outbound links leave this site. We do not host exploit code.
- News archive 2026: security advisory, 21 October 2026 — PHP project (php.net)
- Today’s PHP security release, and how we’re strengthening PHP security — The PHP Foundation
- GHSA-6wmf-4rv5-p3rp — CVE-2026-109619 — PHP (GitHub Security Advisory)
- Security advisory: critical unauthenticated RCE in PHP (“php2shell”) — University of Toronto Information Security
- Notice: php2shell, critical PHP vulnerabilities (status as of 21 October 2026, 20:00 UTC) — Expel
- Critical vulnerabilities in PHP require immediate patching (21 October 2026) — CISA
- Critical security issue affecting PHP — UK NCSC
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — Google Cloud
- CVE-2026-109619 — NVD
- AL26-026 — Critical vulnerabilities impacting PHP — Canadian Centre for Cyber Security