PHP2Shell: Critical PHP Remote Code Execution Vulnerabilities (CVE-2026-109618 and CVE-2026-109619) 

by | Oct 22, 2026 | Blog

By Max Blennemann and Yunfei Ge 

PHP powers a significant portion of the web, underpinning millions of applications, content management systems, and backend services. Because PHP handles core server-side request processing, vulnerabilities within the PHP runtime itself can bypass application-level security controls and expose underlying servers to serious risks. 

On October 21, 2026, the PHP development team released emergency security updates addressing CVE-2026-109618 and CVE-2026-109619, two critical remote code execution (RCE) vulnerabilities collectively known as PHP2Shell. The vulnerabilities affect PHP versions dating back to 5.4 and carry a CVSS v4.0 score of 9.2. With exploitation attempts already observed in the wild, organizations running affected web servers, hosting environments, and cloud infrastructure should prioritize immediate remediation. 

Root Cause 

The vulnerabilities stem from memory management and internal state handling issues within the PHP engine itself, rather than any specific hosted web application: 

  • CVE-2026-109618 (RCE via Out-of-Memory Corruption): Improper handling of out-of-memory (OOM) conditions can interrupt PHP while internal request data is only partially initialized, potentially leading to memory corruption and arbitrary code execution during request cleanup. 
  • CVE-2026-109619 (RCE via Stale Global State): Internal state associated with one request may remain accessible after its underlying memory has been freed. Subsequent requests processed by the same PHP worker can interact with this stale data, potentially leading to arbitrary code execution. 

Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code with the permissions of the affected PHP process. Depending on server permissions, configuration, and isolation controls, attackers could gain access to sensitive data, deploy malicious scripts, move laterally across internal networks, or compromise the underlying server. 

The PHP development team had planned a coordinated disclosure after receiving vulnerability reports in August 2026. However, technical details surfaced online ahead of the scheduled October 21 disclosure. According to Amazon Threat Intelligence, exploitation attempts were detected as early as October 17, four days before public disclosure. Additional proof-of-concept exploits and exploitation attempts appeared around the official release, highlighting the urgency of patching internet-facing PHP deployments. 

RidgeBot Detection 

RidgeBot’s current check uses active validation to assess whether the vulnerable behavior is reachable without authentication. 

After identifying the target PHP service, RidgeBot sends a controlled probe and evaluates the server’s response for behavior associated with the vulnerabilities. This approach provides evidence beyond a version number or service banner. 

Affected Versions 

The following PHP versions are affected, with fixed releases available for supported branches: 

PHP Branch Upstream Support Status Affected Versions Fixed Version 
PHP 8.5 Active Support 8.5.0–8.5.11 8.5.12 
PHP 8.4 Active Support Up to 8.4.26 8.4.27 
PHP 8.3 Security Fixes Only Up to 8.3.35 8.3.36 
PHP 8.2 Security Fixes Only Up to 8.2.34 8.2.35 
PHP 8.1 End-of-Life (EOL) All versions No regular upstream release 
PHP 8.0 End-of-Life (EOL) All versions No regular upstream release 
PHP 7.4 and older (down to 5.4) End-of-Life (EOL) All versions No regular upstream release 

Recommended Action 

The primary remediation is to upgrade affected PHP installations to the fixed versions released on October 21, 2026. 

Security teams should: 

  • Upgrade PHP immediately to version 8.5.12, 8.4.27, 8.3.36, or 8.2.35, as appropriate. 
  • Identify affected installations across web servers, containers, hosting environments, and cloud infrastructure. 
  • Replace end-of-life PHP versions with supported releases or apply trusted vendor-provided security backports where available. 
  • Apply temporary mitigations such as WAF rules, request restrictions, or network isolation if immediate patching is not possible. 
  • Review server logs and process activity for unexpected PHP worker crashes, unusual memory exhaustion, suspicious requests, or unauthorized command execution. 
  • Investigate potential compromises and rotate exposed credentials or secrets if unauthorized access is identified. 

Temporary mitigations may reduce exposure but do not fully address the vulnerabilities. Updating PHP remains the only complete remediation. 

RidgeBot helps security teams validate exposure to PHP2Shell through automated security testing, enabling defenders to identify potentially vulnerable systems and prioritize remediation based on real risk.