The two flaws
Two bugs in the PHP engine, the same severity, the same fix, the same four releases. Both are memory-safety failures in how PHP recovers from an error, and both can be reached by an unauthenticated HTTP request. This page keeps to what the primary records say and marks where they differ.
Fixed in PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 · Vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N · Nickname php2shell (NSA: PHP2Shell) · CNA PHP Group
CVE-2026-109618: RCE via OOM corruption
GHSA-w8hw-w9fx-j79w · CVSS v4.0 9.2 · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:03:58 UTC · advisory 2026-10-21 13:34:25 UTC · CVE record 2026-10-21 13:48:34 UTC
The record's description, verbatim. PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may 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. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).
What was demonstrated. Complete RCE validated over HTTP against mod_php with default input and memory limits, before any application code runs. FPM: susceptible by source analysis; the GitHub advisory says no complete FPM exploit has been demonstrated. FrankenPHP likely susceptible; LSAPI likely but unvalidated.
The fix. Removes longjmp() for OOM. A delayed, graceful soft OOM at the next VM safe point, plus a hard OOM via _exit() at a higher threshold.
CVE record PHP NVD oss-security
CVE-2026-109619: RCE via stale global state
GHSA-6wmf-4rv5-p3rp · CVSS v4.0 9.2 · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:04:00 UTC · advisory 2026-10-21 13:34:13 UTC · CVE record 2026-10-21 13:54:43 UTC
The record's description, verbatim. PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).
What was demonstrated. A use-after-free of worker global state across requests: a producer request and a consumer request on the same worker. Confirmed on the PHP 8.5 fatal-error-backtrace path (the basis of the mod_php exploit) and the session upload progress path, which is enabled by default and needs no session_start(); the session path was validated against mod_php and FPM.
The fix. Part of the same change, "Avoid state corruption via bailout": global state is reset so it cannot refer to freed request memory.
CVE record PHP NVD oss-security
Which deployments
The flaw is in the engine, so what matters is how PHP is wired to the web server. php.net ranks mod_php highest.
| SAPI | Risk | What the primary sources say | Sources |
|---|
| Apache mod_php | highest | Unauthenticated RCE demonstrated over HTTP with default input and memory limits, before any application code runs. | php.net PHP oss-security |
| PHP-FPM | susceptible | For CVE-2026-109618 the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths. For CVE-2026-109619 the session path was validated against FPM. | PHP PHP Foundation PHP oss-security |
| php-cgi | at risk | Listed by php.net among installations serving web requests. | php.net |
| FrankenPHP | likely susceptible | 'likely susceptible' per the GitHub advisory. | PHP |
| LiteSpeed (LSAPI) | likely, unvalidated | 'application-specific exploits being likely but unvalidated'. | PHP |
| CLI, cron, queue workers | not web-serving | The advisory scopes the risk to installations serving web requests. A CLI process that parses untrusted input is not covered either way by the primary sources. | php.net |
What a compromise would mean: the blast radius
This section is the site's own analysis, written from the sources it cites. It is a way of asking the question, not an assessment of any system.
Remote code execution as the web worker is the floor, not the ceiling, and not yet a breach. What an attacker gets is whatever that worker can reach: the application's source and configuration, the database credentials in it, the session store, the files the worker can read or write, the outbound network it can open, and anything that trusts requests from that host. What they do not automatically get is the database server's other schemas, the credentials that were never on that host, or a system behind an allow-list the worker is not on. The blast radius of one compromised PHP worker is therefore a property of the system around it, and that is the first thing to map. The questions, with where the answer usually lives:
- What runs there? A brochure site with no login, a shop with payment data, an intranet with single sign-on, a mail client, an admin panel. The same bug has a different consequence in each. (The NCSC-NL inventory is a start; your asset register is the real answer.)
- What credentials sit on the host? Database passwords, API keys, cloud instance roles, SSH keys in a deploy user's home. A key that cannot be used from anywhere else is a much smaller loss than one that can.
- What can the worker reach outbound? Egress rules decide whether a shell becomes a download of tooling, a callback, or a pivot.
- What trusts the host? Internal services that accept any request from the web tier, shared file systems, backup agents.
- What would you see? CISA's signal is concrete: PHP worker processes launching shells or downloading tools. JPCERT warns that with several exploit paths, one detection rule can miss an attack and a clean log does not prove a clean system.
- How fast can you pull the plug? Taking a system offline is the last step in every agency's list, but the ability to do it in minutes, cleanly, is a property worth having before the next one of these.
CISA JPCERT/CC PHP NCSC-NL
Affected and fixed versions
| Branch | Affected | Fixed | In the CVE record |
|---|
| 8.5 | < 8.5.12 | 8.5.12 | yes |
| 8.4 | < 8.4.27 | 8.4.27 | yes |
| 8.3 | < 8.3.36 | 8.3.36 | yes |
| 8.2 | < 8.2.35 | 8.2.35 | yes |
| 8.1 | end of life; minimal source backport branch PHP-8.1-CVE-2026-109618-109619 | no release | no |
| 8.0 | end of life; minimal source backport branch | no release | no |
| 7.4 | end of life; minimal source backport branch PHP-7.4-CVE-2026-109618-109619, commit 2026-10-18T18:10:24Z | no release | no |
| 5.x to 7.3 | 'all versions from 5 onwards' (NCSC-NL); 'all PHP versions >= 5.4' (Wiz); 'toutes versions 5.x, 6.x, 7.x' (CERT-FR) | no release, no backport | no |
The CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected. The php.net advisory, the backport branches and a Greenbone reply on oss-security say otherwise.
CVE record php.net php-src NCSC-NL Wiz on X CERT-FR oss-security
The temporary mitigations, and what each one does not do
| For | Setting | Caveat, from the same source |
|---|
| CVE-2026-109618 (OOM corruption) | memory_limit=-1, set where applications cannot override it (php_admin_value in the FPM pool or Apache config); check no pool, directory or app setting restores a finite limit. | Removes the controllable memory-limit failure; an underlying allocation failure can still reach the vulnerable path. |
| CVE-2026-109618 | A low post_max_size (8M without uploads, 32M with), upload_max_filesize below it, and web-server or proxy limits on decoded request size, field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length. | Reduces exposure to specific attack paths; does not make an installation safe. |
| CVE-2026-109618 | A container or cgroup memory limit as an availability boundary, killing only the affected worker. | Do not use RLIMIT_AS or RLIMIT_DATA: they can cause the vulnerable allocation failure. |
| CVE-2026-109619 (stale global state) | session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. | Blocks the confirmed session paths only. ini_set() and .user.ini are too late. |
| CVE-2026-109619, PHP 8.5 only | fatal_error_backtraces=0, then restart every worker. | Blocks the confirmed fatal-backtrace path only. |
| CVE-2026-109619 | Remove invalid or deprecated per-request settings that emit diagnostics before initialisation; fix attacker-reachable fatal errors and execution timeouts. | Hiding diagnostics with error_reporting, display_errors or @ does not help. |
| both | pm.max_requests=1 on FPM (GitHub advisory). | 'Updating is the only reliable mitigation.' |
php.net: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.
php.net PHP CERT-EU NCSC-NL
The engineering steps, in order, are on If you run PHP. The disagreement between the two primary accounts of FPM is claim rce-fpm.