php2shell: two critical RCEs in the core of PHP

On 21 October 2026 at 14:00 UTC (1), the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities that allow remote code execution, abbreviated RCE (2), by an unauthenticated attacker. The community had grouped them under the name php2shell even before publication. Both flaws are rated 9.2 on the CVSS (3) version 4.0 scale, critical severity.

CVE (4) CVE-2026-109618, tracked by the project under the GHSA (5) identifier GHSA-w8hw-w9fx-j79w, stems from the handling of out-of-memory conditions, abbreviated OOM (6). CVE-2026-109619, tracked under GHSA-6wmf-4rv5-p3rp, stems from stale global state: internal data belonging to one request outlives the release of its memory and is reused during a later request. Both sit in parts of the engine that nearly every request goes through, which explains both their severity and the difficulty of fixing them without breaking compatibility or degrading performance.

Every installation serving web requests is exposed: PHP-FPM (7), Apache with the mod_php module, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs. The NSA (8) stresses that the flaws lie in PHP itself, not in the hosted application or its configuration: a server running an affected version is exploitable.

The US agency CISA (9) and the NSA published an alert and an advisory on 21 October calling for immediate patching. CERT-FR (10) published alert CERTFR-2026-ALE-014 the same day, updated on 22 October, together with advisory CERTFR-2026-AVI-1359. CISA’s alert lists those of the British, Australian, Dutch, New Zealand and Canadian national centres; the NSA advisory also refers to CERT-EU (11).

Fig. 1. Timeline reconstructed from the PHP Foundation blog post, the php.net archives, the CVE records, the CISA and CERT-FR alerts, the NSA advisory and the watchTowr FAQ.

The delay between the identification of the OOM problem in 2024 and its fix is described by the PHP Foundation as a structural failure. In 2024, no path to code execution was known, and the security team, small and operating by consensus, did not settle between several fixes with opposing drawbacks: compatibility breaks, denial-of-service risk, or changes to coordinate across many third-party extensions. The fix became the team’s priority from 11 August 2026, when several reports established the real scope of the problem. The Foundation states that it has since begun moving to majority decision-making on security matters.

Credits

The CVE records published by the PHP Group credit Ryan, of Calif, and Wiz as reporters of both vulnerabilities; OpenAI appears as reporter of CVE-2026-109619 and as finder of CVE-2026-109618. The fix is credited to Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche. The PHP Foundation states that AI-assisted analysis tools, including those made available to it by OpenAI and Anthropic, are used to validate reports and to group those sharing a root cause, with every decision and every patch remaining the work of a developer.

For the supported branches, all sources agree: each branch receives a single fixed release that covers both CVEs. For the unsupported branches, three readings coexist. The CNA’s CVE records list only four affected ranges, from 8.2 to 8.5, with a default status of “unaffected” for any version not listed. The CERT-FR alert lists all 5.x, 7.x, 8.0.x and 8.1.x versions as affected. Finally, the PHP project published fix backports for 7.4, 8.0 and 8.1, which amounts to treating them as vulnerable, without listing them in its records.

Fig. 2. Affected versions according to the CVE-2026-109618 and CVE-2026-109619 records published by the PHP Group, alert CERTFR-2026-ALE-014 in its 22 October 2026 version and the php.net security advisory. Version numbers compared character by character across these sources and the two GHSA advisories.

CERT-FR points out that the vendor no longer supports the 5.x, 7.x, 8.0.x and 8.1.x branches. watchTowr, in its FAQ updated on 23 October, states that it has confirmed that older unsupported branches, including PHP 5, are affected, and classes 7.3 and earlier as having no fix available. The source backports provided by the project for 7.4, 8.0 and 8.1 are aimed at those who build PHP themselves or have no long-term support vendor; they are not published releases.

The records also carry two third-party data containers: an ADP (14) container from CISA and an SADP (15) container from Siemens, the mechanism through which a supplier publishes information specific to its own products. The content of these containers does not appear in the version of the records consulted.

Distributions, containers and version checks

Linux distributions and long-term support vendors received the fixes in advance. An installation that follows its distribution’s packages may show an unchanged version number, the fix being backported into the packaged version without an upstream version bump; verification is then done against the package changelog. The check applies to the engine that actually serves requests, PHP-FPM or mod_php, whose version may differ from that of the command-line interpreter. After updating, every worker must be restarted for the fix to take effect.

PHP is often embedded in other software, and its presence is not always directly visible: CISA and CERT-FR ask for the inventory to be extended to products, appliances and containers that include a PHP component, beyond the web servers identified as such.

PHP uses the longjmp() call to abort the handling of a request when it exceeds the memory_limit and to leave the current context. In some contexts, a request’s memory is briefly reachable before it is fully initialised. If an allocation fails at that moment, PHP does not account for the early exit and leaves the request’s memory in an invalid state. The failing allocation does not need to be related to the invalid area. The request shutdown procedure then reads that state or branches on it; several OOM strategies trigger this condition reproducibly and lead to code execution.

Reaching OOM while staying within apparent limits

The attacker triggers the out-of-memory condition at will. Advisory GHSA-w8hw-w9fx-j79w describes several flaws in multipart request parsing that make this possible while staying within PHP’s stated limits:

• a multipart request without a usable declared content length passes the initial post_max_size check and keeps supplying decoded body data
• a multipart part can carry an unbounded number of headers, whose in-memory representation by PHP consumes far more than their representation on the wire, exhausting memory_limit while staying under post_max_size
• empty file controls do not count towards max_file_uploads but still create the usual metadata arrays, and nested field names multiply the allocation work

OOM can also be reached through application-specific paths, whenever attacker-controlled input causes a sufficiently large allocation or repeated memory use.

The fix

The fix removes the longjmp() call from OOM handling and replaces it with two mechanisms: a soft, delayed OOM, raised at the next safe point of PHP’s virtual machine, and a hard, immediate OOM that calls _exit() if memory consumption reaches a second, higher threshold. The shutdown procedure no longer sees invalid state, and PHP’s ability to limit memory consumption is retained. The vulnerability is classified under CWE (16) weaknesses 416 (use after free), 755 (improper handling of exceptional conditions), 824 (access of uninitialised pointer), 1325 (improperly controlled sequential memory allocation) and 1419 (incorrect initialisation of resource).

The confirmed impact is unauthenticated remote code execution with the privileges of the web worker account. Complete code execution was validated against mod_php with default memory and input limits and an ordinary prefork configuration with several workers. Additional workers and unrelated traffic increase the number of attempts required without removing the condition; the portability and reliability of the exploit depend on the PHP build, the extensions, the behaviour of the frontend and the allocator layout.

PHP keeps various global state in each worker: error, session, object or extension state. This state points to memory owned by a single request and must be reset before that memory is released. Some input, configuration, session and error handling operations run before the normal initialisation of the next request. They then access stale state that the previous request did not reset, which results in a use after free; a heap layout, the area of dynamically allocated memory, prepared by the attacker leads to code execution.

Producer and consumer

Exploitation requires two distinct operations. The producer is a PHP operation that stores state owned by one request in a location reachable later. The consumer is an operation in a subsequent request that reads this stale state, frees it or branches on it, before normal initialisation resets it. Both occur in different HTTP (17) requests handled by the same worker.

State can survive for two reasons. A fatal error, including one caused by memory exhaustion, abandons an operation before the matching reset. A warning or another non-fatal diagnostic can also repopulate the error state after it was cleared during shutdown.

Fig. 3. Producer and consumer cases described by advisory GHSA-6wmf-4rv5-p3rp. Session upload progress is enabled by default and requires no application call to session_start().

For the session upload progress lifecycle, the application-independent trigger is an OOM during input processing. With mod_php, the producer and the fatal error can both occur during multipart startup; the validated FPM variant publishes state during application execution, reaches a fatal error, then uses session upload progress as the early consumer, which requires a suitable application operation. For configuration diagnostics, the advisory cites in particular deprecated settings such as auto_detect_line_endings=1, explicitly configured mbstring or iconv settings, malformed memory_limit values and paths rejected by open_basedir. With mod_php, directory configuration and .htaccess files are applied before request initialisation; with FPM, exposure depends on the PHP_VALUE and PHP_ADMIN_VALUE parameters sent by the frontend.

The confirmed impact is an unauthenticated use after free, memory disclosure and remote code execution with the privileges of the web worker. The weaknesses listed are the same as for CVE-2026-109618: CWE-416, 755, 824, 1325 and 1419.

PHP’s execution mode determines the level of risk, because it decides whether the request shutdown procedure is called even when startup has failed.

Fig. 4. Exposure by execution mode, according to the two GHSA advisories. “Validated” means a complete exploit was demonstrated; “assessed as susceptible” refers to source analysis without a complete exploit.

Apache mod_php calls the request shutdown procedure unconditionally, even when startup has failed. During that startup, automatic body parsing can exhaust the memory limit and exit the request in a context where the state is temporarily invalid, which shutdown then processes, before any application code. PHP-FPM, by contrast, terminates the child process when startup fails, which blocks this specific path and removes the process from the pool; source analysis nevertheless assesses it as exposed through other routes, and CVE-2026-109619 has been successfully exploited on it.

Both GHSA advisories insist on one point: only updating provides complete protection. The measures below reduce exposure to specific attack paths without making an installation safe. They must be set in configuration applied before request parsing, php.ini, the FPM pool or the server configuration, never through ini_set() or an FPM .user.ini file. Every change requires all workers to be restarted.

Against OOM corruption (CVE-2026-109618)

• set memory_limit=-1, preferably in a way applications cannot override, for example with php_admin_value in the FPM pool or the Apache configuration, and check that no pool, directory or application setting restores a finite limit. This removes the controllable memory limit failure, but an underlying allocation failure, for example of mmap(), can still reach the vulnerable path
• keep post_max_size low, 8M without file uploads and 32M with them, keep upload_max_filesize below post_max_size, reduce max_input_nesting_level, and enforce upstream, at the web server or proxy, limits on decoded size and on the number of fields, multipart parts, headers per part and uploads, including for requests without a usable content length; block multipart requests before they reach PHP if the application does not use them
• use a container or cgroup memory limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, which make mmap() fail and trigger precisely the vulnerable path

Against stale global state (CVE-2026-109619)

• set session.upload_progress.enabled=0 and restart every worker: blocks the confirmed session paths, not the other variants, and does nothing for CVE-2026-109618
• on PHP 8.5, set fatal_error_backtraces=0 and restart every worker: blocks only the confirmed fatal error backtrace path
• remove invalid or deprecated settings applied per request that emit a diagnostic before initialisation; hiding diagnostics through error_reporting, display_errors or the @ operator offers no protection
• fix fatal errors and execution timeouts reachable by an attacker, including in callbacks, upload or import processing, destructors and cleanup; where performance is not a constraint, limit each worker to one request with pm.max_requests=1

The three authorities whose publications were consulted converge on immediate updating and on taking offline or isolating systems that cannot be patched. They differ in their supporting measures.

Fig. 5. Recommendations from CISA, the NSA and CERT-FR, based on their publications of 21 to 23 October 2026.

The blocking of multipart requests recommended by CERT-FR goes beyond the project’s measure, which reserves it for applications that do not use this type of request: it stops all file uploads. It covers the multipart parsing OOM strategies of CVE-2026-109618 and the session upload progress path of CVE-2026-109619, which relies on an upload. It covers neither the fatal error backtrace path on PHP 8.5 nor application-specific paths. The php_admin_flag parameter mentioned by CERT-FR meets the same requirement as the GHSA advisories: setting the value at a level that the application cannot override and that applies before request parsing.

The coordinated disclosure went off track two days before the planned release date. On 20 October 2026, the two CVE identifiers circulated with a wrong release time and a wrong score, without technical details. The project brought its pre-announcement forward and moved the release from 22 to 21 October, a compromise between speed and the time left for distributions to package the fix. The demonstration video mistakenly published by Calif revealed a few additional details and, according to the PHP Foundation, accelerated the development of PoCs. The mitigation advice shared with a few critical infrastructure providers around 23:00 UTC on 20 October may also have leaked. On 21 October at 07:41 UTC, Chainguard published images containing the fix, exposing it to analysis in binary form more than six hours before other users had access to the update.

Findings on exploitation differ between sources and should be kept apart:

• the PHP Foundation states that it inspected the PoCs that appeared after the leak without identifying any functional exploit at the time of disclosure
• CISA wrote on 21 October that it had not observed successful exploitation
• CERT-FR stated on 22 October that it was aware of PoCs for specific PHP deployments
• watchTowr reports observing exploitation in the wild since 21 October in its honeypot network, and maintains this finding in its FAQ updated on 23 October
• as of 25 October 2026, neither CVE appears in CISA’s KEV (20) catalogue, a finding already made by watchTowr as of 22 October; the CISA alert updated on 23 October does not mention any addition
• no attribution to an actor has been made public

Exploitation typically shows up as abnormal child processes launched directly by PHP worker processes, for example a command interpreter spawned by php-fpm, php-cgi, httpd or apache2. CISA recommends monitoring PHP workers that launch shells or download tools, and provides a Sigma rule in its GitHub repository, which it says may be updated. CERT-FR advises monitoring multipart requests when they cannot be blocked.

A configuration and logging audit complements detection. Enabling log_errors=On, a functional error_log and error_reporting=E_ALL in the startup configuration, for the duration of an isolated review, helps identify in the Apache, PHP-FPM, proxy and service logs:

• warnings, deprecations and core errors repeated before the target scripts run
• diagnostics produced during extension or server cleanup
• fatal, parse and uncaught errors, and Maximum execution time exceeded messages
• failures limited to routes, content types, files or options controlled by an attacker

The absence of errors in the logs does not prove the absence of vulnerability: historical logs may have excluded deprecations, even an exhaustive review only covers the paths actually exercised, and a failure can occur before the message is written. If a compromise of an exposed server is suspected, CERT-FR refers to its reflex sheet on containing a compromised edge device, CERTFR-2025-RFX-002.

The two GHSA advisories, the CVE records, the php.net security advisory and archives, the PHP Foundation blog post, and the CISA, NSA and CERT-FR publications are primary sources, read in full. The watchTowr FAQ is a vendor source. Versions and the CVSS vector were cross-checked across these sources.

1. UTC (1): Coordinated Universal Time.
2. RCE (2): Remote Code Execution.
3. CVSS (3): Common Vulnerability Scoring System, the system used to rate the severity of vulnerabilities.
4. CVE (4): Common Vulnerabilities and Exposures, the public identifier assigned to a vulnerability.
5. GHSA (5): GitHub Security Advisory, a security advisory identifier assigned by GitHub.
6. OOM (6): Out Of Memory, exhaustion of available or permitted memory.
7. PHP-FPM (7): PHP FastCGI Process Manager, PHP’s FastCGI process manager.
8. NSA (8): National Security Agency, the United States signals intelligence and national security systems cybersecurity agency.
9. CISA (9): Cybersecurity and Infrastructure Security Agency, the United States cybersecurity and infrastructure security agency.
10. CERT-FR (10): the French government computer emergency response team, part of the Agence nationale de la sécurité des systèmes d’information (ANSSI).
11. CERT-EU (11): the cybersecurity service for the institutions, bodies and agencies of the European Union.
12. CNA (12): CVE Numbering Authority, an organisation authorised to assign CVEs and publish their records; here, the PHP Group.
13. PoC (13): Proof of Concept, code demonstrating that exploitation is feasible.
14. ADP (14): Authorized Data Publisher, an organisation authorised to enrich a CVE record with additional data.
15. SADP (15): Supplier Authorized Data Publisher, a supplier authorised to publish in a CVE record information specific to its own products.
16. CWE (16): Common Weakness Enumeration, a classification of software weaknesses.
17. HTTP (17): Hypertext Transfer Protocol, the web’s transfer protocol.
18. LSAPI (18): LiteSpeed Server Application Programming Interface, the interface used to run PHP under LiteSpeed.
19. WAF (19): Web Application Firewall.
20. KEV (20): Known Exploited Vulnerabilities, CISA’s catalogue of vulnerabilities whose exploitation has been observed.
21. LLM (21): Large Language Model.

1. PHP, Security advisory: Critical remote code execution vulnerabilities, update now, 21 October 2026. php.net/archive/2026
2. PHP (GitHub php-src), RCE via OOM corruption, advisory GHSA-w8hw-w9fx-j79w, 21 October 2026. github.com/php/php-src
3. PHP (GitHub php-src), RCE via stale global state, advisory GHSA-6wmf-4rv5-p3rp, 21 October 2026. github.com/php/php-src
4. CVE Program, record CVE-2026-109618, CNA PHP Group, published 21 October 2026. cve.org
5. CVE Program, record CVE-2026-109619, CNA PHP Group, published 21 October 2026. cve.org
6. The PHP Foundation, Today’s PHP Security Release, and How We’re Strengthening PHP Security, 21 October 2026. thephp.foundation
7. CISA, Critical Vulnerabilities in PHP Require Immediate Patching, 21 October 2026, updated 23 October 2026. cisa.gov
8. NSA, NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities, 21 October 2026. nsa.gov
9. CERT-FR, [Màj] Multiples vulnérabilités dans PHP, alert CERTFR-2026-ALE-014, 21 October 2026, updated 22 October 2026. cert.cyber.gouv.fr
10. watchTowr, Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 & CVE-2026-109619), 20 October 2026, updated 23 October 2026. watchtowr.com
11. PHP, Informational advisory: Session upload progress, 23 October 2026. php.net/archive/2026
12. CISA, Known Exploited Vulnerabilities catalogue, accessed 25 October 2026. cisa.gov/known-exploited-vulnerabilities-catalog