PHP2Shell: Critical PHP Vulnerabilities Expose Web Servers to Unauthenticated Code Execution

Overview

Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated attackers to execute code on affected web servers. Known collectively as PHP2Shell, these vulnerabilities affect the PHP runtime that powers websites, content management systems, and business applications.

Both vulnerabilities carry a CVSS v4.0 score of 9.2. PHP released security updates on October 21, 2026. Organizations should assess their PHP deployments and apply the appropriate updates immediately. ¹

In this article, we explain the vulnerabilities, the evidence defenders should investigate, and how security validation can help assess detection coverage.

Background

PHP processes incoming web requests before passing control to an application. During this stage, it may parse form fields, handle uploaded files, and initialize session data.

CVE-2026-109618: Memory Corruption During Error Handling

An out-of-memory error can interrupt PHP while internal request data is only partially initialized. During cleanup, PHP may treat that incomplete data as valid, creating a path to code execution.

Researchers demonstrated unauthenticated exploitation against Apache mod_php before application code executes. Crafted multipart requests can cause PHP to allocate substantially more memory than their transmitted size suggests.

CVE-2026-109619: Stale State Between Requests

A PHP worker may retain references to memory that was freed after an earlier request. If the same worker processes another request, certain operations can access those references before normal initialization clears them.

The affected paths include session upload progress and error handling. Exploitability depends on the PHP version, server configuration, and application behavior. PHP-FPM and Apache mod_php do not handle every failure in the same way.

Successful exploitation can give an attacker code execution with the web worker's privileges.

Additional Research Findings

Researchers demonstrated memory disclosure without code execution: stale session state can expose worker memory through a PHPSESSID response cookie, potentially revealing credentials and tokens. The demonstrated path does not require the application to call session_start().

Researchers also described OPcache type confusion across workers. OPcache caches compiled PHP code; interrupted updates can leave shared metadata referring to the wrong runtime object. These findings show why investigation must cover responses and worker activity as well as incoming requests. ²

Readiness Assessment

For security teams, PHP2Shell raises a practical question: would our controls identify suspicious request activity and the server behavior that follows?

A validation exercise should assess whether HTTP inspection recognizes the documented request patterns, whether PHP errors reach the SOC, and whether endpoint monitoring identifies unexpected commands launched by web workers.

HTTP simulation can help evaluate how controls inspect representative traffic. Its results should be interpreted within that scope: detecting a simulated request does not confirm that the underlying PHP vulnerability has been patched.

Mitigation

1. Apply the PHP security updates. Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or a vendor package containing the corresponding fixes.
2. Inventory embedded PHP installations. Include hosting platforms, containers, appliances, and applications that bundle their own runtime.
3. Review unsupported versions. Upgrade where possible, or verify that your distribution or support provider supplies the relevant fixes.
4. Apply temporary controls carefully. PHP documents configuration changes that reduce exposure to particular attack paths. These measures provide partial protection and do not replace patching. ¹

Detection

Some affected operations occur before application initialization, so application logs may provide little context. Review reverse-proxy, PHP runtime, and endpoint evidence together. ²

Relevant investigation signals include:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
• Unexpected PHP worker failures or repeated worker restarts.
• Abnormally large or malformed PHPSESSID response cookies.
• Unexpected shell or command execution originating from PHP or web-server workers.

Request anomalies, memory errors, cookie abnormalities, and worker churn are useful investigation signals. They are not individually conclusive evidence of exploitation. Legitimate uploads and application failures can produce overlapping symptoms. ²

Conclusion

PHP2Shell demonstrates how weaknesses in a shared runtime can expose otherwise secure applications. Organizations should prioritize PHP updates and verify that their monitoring captures evidence across HTTP traffic, application errors, and endpoint activity.

For Thawd, security validation begins with a clear scope and observable evidence. Testing those defensive capabilities helps teams understand what their controls can detect and where further investigation or tuning is required.

Sources

1. PHP Security Advisory: Critical Remote Code Execution Vulnerabilities - Official release announcement, fixed versions, and mitigation guidance.
2. PHP Advisory: RCE via OOM Corruption (CVE-2026-109618) - Root cause, deployment differences, and remediation.
3. PHP Advisory: RCE via Stale Global State (CVE-2026-109619) - Request lifecycle flaws, affected paths, and mitigation limits.

‍