[CS-SA-26-1002] PHP2SHELL RCE Vulnerabilities
Download the Advisory (PDF)The CRITICALSTART® Cyber Research Unit (CRU) is tracking PHP2Shell, the name for two critical flaws in the PHP: Hypertext Preprocessor (PHP) runtime, tracked as Common Vulnerabilities and Exposures (CVE) identifiers CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution (RCE) with the privileges of the web worker account, and PHP rates each 9.2 on Common Vulnerability Scoring System (CVSS) version 4.0. PHP and its research partners disclosed the flaws on October 21, 2026, after a leak on October 20 forced a release one day ahead of the planned October 22 disclosure. The flaws stem from how PHP handles fatal errors, particularly out-of-memory (OOM) errors, during request processing. A request that ends abnormally can leave corrupted state behind, and a later request on the same worker can reuse it. CRU has not identified any known threat actor and the sources reviewed describe it without attribution. PHP released fixes on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Every PHP deployment that serves web requests on an unpatched release is exposed, and the flaws sit in the runtime rather than in any application.[1, 2] PHP runs on 69.3% of websites with a known server-side language, according to W3Techs. That figure measures PHP adoption not confirmed vulnerable sites.[4, 6] Estimates put the number of internet-exposed PHP hosts between 1.3 million and 5.1 million. Researchers report exploitation attempts prior to patch release. CISA, NSA, and other authorities have put out advisories and mitigation guidance. Organizations should inventory every PHP runtime that serves web requests, patch internet-facing systems first, and restart PHP processes after updating.
| CVE | CVSS v4.0 | Description |
|---|---|---|
| CVE-2026-109618 | 9.2 | RCE via out-of-memory (OOM) corruption. Request memory is left in an invalid state when an allocation fails during early request handling.[1] |
| CVE-2026-109619 | 9.2 | RCE via stale global state. Request-owned state survives after its memory is freed and is reused by a later request on the same worker.[2] |
Both flaws corrupt PHP’s memory when a request ends abnormally. This section summarizes the mechanisms in PHP’s advisories and omits exploitation detail. Both CVEs share the 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. Attack complexity is rated High and attack requirements are present. PHP states that exploit reliability depends on the PHP build, extensions, frontend behavior, and memory allocator layout.[1, 2]
| Branch | Affected | Fixed | Notes |
|---|---|---|---|
| PHP 8.5 | Before 8.5.12 | 8.5.12 | Supported branch.[1, 2] |
| PHP 8.4 | Before 8.4.27 | 8.4.27 | Supported branch.[1, 2] |
| PHP 8.3 | Before 8.3.36 | 8.3.36 | Supported branch.[1, 2] |
| PHP 8.2 | Before 8.2.35 | 8.2.35 | Reaches end of life on December 31, 2026.[8] |
| PHP 8.1 and older | Reported affected back to PHP 5.4[3, 4] | - | PHP provides minimal source backports for 7.4, 8.0, and 8.1. Distributions and long-term support (LTS) vendors may provide their own backports.[5, 7] |
PHP uses a jump function, longjmp(), to abandon a request when memory runs out. In some contexts, request memory is reachable before PHP fully initializes it. If an allocation fails at that point, request cleanup reads invalid state, which can lead to code execution.[1] PHP’s advisory identifies several multipart request parsing problems that can push a request to the memory limit while it stays within its apparent size limits.[1] On Apache mod_php, this happens entirely before application code begins to run.[1]
A PHP worker handles many requests in sequence. Some internal state, including error, session, object, and extension state, can still point to memory that a finished request owned. A later operation on the same worker can use that stale state before PHP re-initializes it, which creates a use-after-free condition that can lead to code execution.[2] Exploitation requires a producer, which leaves stale state behind after a fatal error or memory exhaustion, and a consumer, which acts on that state in a later request on the same worker.[2] PHP confirms two consumers: diagnostics raised while applying configuration before request initialization, and session upload progress handling.[2] Two cases are confirmed. A PHP 8.5 fatal error backtrace path has demonstrated mod_php exploitation, and a session upload progress path was validated against both mod_php and PHP-FPM.[2] Session upload progress is enabled by default, and the application does not need to call session_start() for it to be reachable.[2] Running multiple workers lowers the success rate per request but does not remove the condition.[2]
Wiz reports that an attacker could read sensitive process memory, including passwords, tokens, application programming interface (API) keys, and certificates, without achieving code execution.[3] PHP’s advisory for CVE-2026-109619 also lists memory disclosure as a confirmed impact.[2] Wiz demonstrated unauthenticated RCE against default container images of WordPress, Drupal, and Joomla, and states that exploitation does not depend on a flaw in the application.[3]
Risk differs by how PHP connects to the web server. PHP rates Apache mod_php highest because an unauthenticated request can trigger the attack before any application code runs.[7]
| Server Application Programming Interface (SAPI) | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
Apache mod_php | RCE validated over Hypertext Transfer Protocol (HTTP) with default input and memory limits.[1] | RCE validated through the PHP 8.5 fatal backtrace path and the session upload progress path.[2] |
| PHP-FPM | Susceptible after normal startup by source analysis. No complete exploit demonstrated.[1] | Session lifecycle RCE validated. It depends on a suitable operation inside the application.[2] |
| FrankenPHP | Likely susceptible to application-independent attacks. Source analysis only.[1] | No early consumer established in the default configuration. Application or extension behavior may still expose it.[2] |
| LiteSpeed Server Application Programming Interface (LSAPI) | Application-specific exploits likely. Unvalidated.[1] | Conditional candidate through early environment settings.[2] |
The mapping below, drawn from the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework, describes behaviors that are in scope:[5]
| Technique | Name | Context |
|---|---|---|
| T1190 | Exploit Public-Facing Application | Crafted HTTP requests trigger memory corruption in PHP on internet-facing web servers.[1, 2, 4] |
| T1059 | Command and Scripting Interpreter | PHP worker processes spawn shells or interpreters after code execution.[5] |
| T1059.004 | Unix Shell | PHP worker processes spawn shells or interpreters after code execution.[5] |
| T1505.003 | Server Software Component: Web Shell | Attackers may place web shells in the web root for persistence.[5] |
| T1105 | Ingress Tool Transfer | Download utilities such as curl and wget retrieve additional tools.[5] |
| T1033 | System Owner/User Discovery | Commands such as whoami and id run from the web server process.[5] |
| T1082 | System Information Discovery | Commands such as uname -a run from the web server process.[5] |
| T1082 | System Network Configuration Discovery | Network discovery commands run can be indicators |
The central risk is that these flaws sit below the application layer. Updating WordPress, its plugins, or any application code does not patch the PHP runtime that serves it, so each organization needs to confirm the runtime version on every host.[4, 13] PHP often runs where teams do not track it. Control panels, vendor appliances, containers, and Windows software that bundles PHP can all carry an affected runtime, and managed hosting customers depend on their provider to patch.[5, 13] Impact depends on the account PHP runs as. Successful exploitation yields code execution with the web worker’s privileges, which does not automatically grant administrator control of the server.[1, 2, 13]
The worker can still reach application files, credentials, and secrets available to that process, and Wiz reports that memory disclosure alone can expose passwords, tokens, API keys, and certificates.[3, 13] Organizations that suspect exploitation should treat those secrets as exposed.
Configuration changes reduce risk but do not remove it. PHP states that updating is the only complete mitigation for both flaws, and that no generic configuration change covers every stale-state path.[1, 2] Cloudflare describes its web application firewall (WAF) rules as an additional layer of defense in depth, and those rules protect only traffic that passes through Cloudflare.[4, 6]
Unsupported PHP is the main structural exposure. PHP 8.1 and older receive no official update, and PHP 8.2 reaches end of life on December 31, 2026.[7, 8] Organizations that run these branches need a vendor backport, a source backport, or an upgrade.[5, 7] The fix also changes memory behavior. The patch adds a hard memory limit that ends the process when reached, so teams should review memory_limit and post_max_size after updating.[1, 8]
Note: Patching does not finish remediation until PHP restarts. Installing the fixed package does not load the patched runtime into running processes. Restart Apache, PHP-FPM, and every long-running PHP worker.[8, 12] If a host may have been exposed before patching, rotate the secrets that the PHP process could read.
These flaws execute below the application layer, so application logs may contain little context.[3] Treat the signals below as leads for investigation, not proof of compromise. Applying the PHP security update remains the only complete remediation.[3]
PHPSESSID response cookies.[3]Maximum execution time exceeded messages.[2]php-fpm, php-cgi, httpd, or apache2 launching shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl), or download and network tools (curl, wget, nc, certutil.exe).[5]/dev/tcp/, fsockopen, and mkfifo.[5]whoami, id, uname -a, and ipconfig run from the web server.[5]No indicators of compromise (IOCs) have been confirmed in the sources reviewed as of October 21, 2026.[5] If a host shows suspicious activity, isolate it and preserve its web server and PHP logs.[5]
To improve your organization’s security posture considering the PHP2SHELL Vulnerability exploitation, CRU recommends the following:
php.exe or php-cgi.exe. Start with internet-facing systems, and treat Apache mod_php and FrankenPHP hosts as the highest priority.[1, 5]session.upload_progress.enabled=0 in php.ini, the PHP-FPM pool, or server configuration, not through ini_set() or .user.ini, and restart every worker.[2, 7] On PHP 8.5, also set fatal_error_backtraces=0.[2] Set and enforce memory_limit=-1 administratively, keep post_max_size low, and enforce request size limits at the web server or proxy.[1] If the application does not use multipart forms, block multipart requests before they reach PHP.[1] Do not use RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable allocation failure path.[1] Unlimited memory raises denial-of-service risk on shared servers, so apply it deliberately. These steps reduce exposure to specific paths only.[1, 2].htaccess, Apache php_value, or nginx PHP_VALUE. Fix fatal errors and execution timeouts that an attacker can trigger, including in upload and import handling.[2] Consider leaving session.upload_progress.enabled=0 in place after patching if the application does not use the feature.[2]memory_limit and post_max_size against application needs.[1, 8]PHP2Shell affects the PHP runtime that serves a large share of the web, and fixed versions are available now for supported branches. Updating the runtime and restarting PHP processes is the only complete remediation, and interim configuration changes reduce exposure only along specific paths. Organizations should patch internet-facing systems first, isolate unsupported PHP, and hunt for signs of compromise using the guidance above. For more threat reports, including H2 2025 detailing trending cybersecurity concerns visit Critical Start’s Intel Hub. Should anything new surface, this advisory will be updated. This advisory was written using the best intelligence available at the time and is subject to change as additional information becomes available.
Critical Start is actively threat hunting for vulnerable versions and will be contacting customers through established channels for remediation. Likewise, the Security Engineering team is building applicable activity-based detections for global deployment. CRU continues to actively monitor the situation and work closely with the SOC for heightened vigilance. For future updates, CRU will post updates via Cyber Operations Risk & Response™ Bulletins and on the CRITICALSTART® Intelligence Hub.