PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Pre-Auth RCE in PHP Core Puts Web Servers at Risk

Two critical vulnerabilities in the PHP core, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, let an unauthenticated attacker run commands on servers that use an affected PHP build to handle web requests. PHP released fixes on October 21, 2026, a day after details leaked online. Public proof-of-concept code followed within hours, and exploitation attempts were seen as early as October 17. 

AppTrana customers have been protected against PHP2Shell. This blog covers how the vulnerabilities work, how AppTrana detects and blocks exploitation attempts, and the steps we recommend to secure affected PHP deployments. 

What is PHP2Shell? 

Risk Analysis

• Severity: Critical (CVSS v4.0 9.2 for each CVE) 
• Attack vector: Network, no authentication 
• Exploitation: Public PoCs and in-the-wild attempts.  
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. 

PHP2Shell was found by Wiz Research, OpenAI Codex Security and Calif, working with the PHP security team. Both vulnerabilities are rooted in how PHP cleans up after a request fails: 

CVE-2026-109618, out-of-memory corruption

When a request uses up all the memory PHP is allowed, PHP stops halfway and leaves some of its internal request data half-built. The clean-up that runs at the end of the request then treats this half-built data as if it were complete. An attacker can trigger this with a specially crafted file upload. 

CVE-2026-109619, stale global state

After a fatal error, PHP does not clear some data that still points to memory it has already freed. The next request handled by the same worker (a PHP process that serves web requests) can then use this stale data. Confirmed attack paths include the session upload progress feature, which has been on by default since PHP 5.4. 

An attacker sends a specially crafted POST request to an internet-facing PHP endpoint, with no login needed. The bug is triggered while PHP is still parsing the request, so the exploit runs before any application security controls get a chance to act. PHP has confirmed that attackers can gain full remote code execution (RCE) on Apache with mod_php, the highest-risk setup, and run code on PHP-FPM through the session upload progress feature. 

Affected Versions 

All PHP installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. 

On October 20, the threat intelligence firm Mallory counted roughly 884,000 internet-facing hosts advertising PHP 8.1 or older in their HTTP banners. Some Linux distributions copy the security fix into an older PHP version without changing its version number. A server that shows an old version may therefore already be patched, so check the package changelog to confirm. Move end-of-life systems to PHP 8.3 or later, as 8.2 reaches end of life on December 31, 2026. 

What PHP2Shell Means for Your Web Infrastructure 

The impact of PHP2Shell goes beyond a single application. Any PHP-based site, such as WordPress, Magento or Laravel, is exposed if it runs on an affected PHP version. The same applies to custom PHP applications and APIs. 

• Code Execution on the Web Server: A successful exploit gives the attacker command execution with the privileges of the PHP process (the PHP-FPM worker, or the Apache user with mod_php). From there, the attacker can install a web shell (a hidden script that gives them ongoing control of the server), read application source code, and change files served to users. 

• Credential Theft and Lateral Movement: PHP processes usually access database passwords, API keys, and cloud credentials in configuration files or environment variables. Once these are stolen, the attacker can move into databases, cloud accounts, and internal services. 

• Wide Blast Radius on Shared Infrastructure: On shared hosting, a single compromised worker can expose many customer sites at once. Ecommerce platforms face the added risk of payment skimming scripts injected into checkout pages. 

• Unauthenticated Access Increases Exposure: Attackers do not need to log in. Any PHP page on the internet that accepts submitted data (a POST request) can be a target. Once a working exploit is public, automated tools can scan millions of servers very quickly. 

• Silent Compromise: A successful attack can look like a normal request. The server often replies with a standard “200 OK” message, so regular monitoring shows nothing unusual. In container setups such as Kubernetes, the system that manages the containers may also replace a hacked container with a fresh one, which wipes out the evidence before anyone can collect it. 

PHP2Shell: From Leak to Public PoC in 24 Hours 

Public proof-of-concept (PoC) code for PHP2Shell appeared within about a day of the details leaking online. Defenders lost the head start they normally get. Patches are usually ready before exploit code goes public, which gives teams time to test and install them. This time, attackers had working exploits first, so teams that relied on patching alone were exposed. The timeline below shows how events unfolded: 

• October 17: Amazon Threat Intelligence records an exploitation attempt against its honeypots, four days before the fix. 
• October 20: Details leak online. watchTowr confirms the vulnerabilities are real, and PHP announces an emergency release. 
• October 21: PHP releases the patches at 14:00 UTC. Scanning starts hours earlier, PoCs appear on GitHub within hours, and watchTowr and Patchstack report exploitation attempts. 

How to Detect PHP2Shell 

• Inventory every PHP runtime, including PHP-FPM pools, container images, control panels and appliances. Then look for: 
• Requests: POST requests that include a PHP_SESSION_UPLOAD_PROGRESS field (or the custom name set in session.upload_progress.name) and go to pages that do not accept uploads. Also look for requests with hundreds of empty file fields, very long or deeply nested field names, and sudden bursts of large POST requests. Requests from the public exploit tool may also carry user agents containing php2shell or boundaries starting with —-p2s, but attackers can change these easily. 
• Server logs: errors containing “Allowed memory size” and worker crashes, such as Apache AH00052 errors (child process exited with a segmentation fault). 
• Host activity: PHP processes that start shells or download tools such as sh, bash, curl or wget. Also look for new PHP files in upload or temp folders and outgoing connections to unknown servers. 

Detection matters even on servers you have already patched. A patch closes the vulnerability, but it does not remove an attacker who got in before the fix. After upgrading, search for web shells and review logs from the whole period when the server was exposed. 

PHP2Shell: Mitigation and Remediation 

Upgrade to the fixed release for your branch, starting with servers that run Apache with mod_php. Restart every PHP worker and rebuild container images that bundle PHP. If a vulnerable server was reachable from the internet, rotate the database passwords, API keys and cloud credentials available to PHP. 

If you cannot patch immediately, PHP’s advisory lists settings that reduce, but do not remove, exposure. Set them in php.ini or the PHP-FPM pool configuration, and restart every worker: 

session.upload_progress.enabled = Off
fatal_error_backtraces = 0 ; PHP 8.5 only
memory_limit = -1 ; pair with a container or cgroup memory limit
post_max_size = 8M ; 32M if file uploads are needed

Because these settings only reduce the risk, add a web application firewall (WAF) as a compensating control, a safeguard that covers the gap until you can patch. Not every WAF has protection for PHP2Shell. Even when it does, the rule must run in block mode, to stop attacks. Test your WAF with PHP2Shell payloads and confirm it blocks them. Once confirmed, it keeps your applications protected while you roll out the patch. Patching remains the permanent fix, so plan your upgrade alongside WAF coverage. 

AppTrana WAAP Coverage for PHP2Shell 

AppTrana WAAP  customers have been protected from PHP2Shell. Coverage has since been strengthened as more exploit details emerged. 

• Out-of-the-box protection: AppTrana’s default security policies inspect every request body before it reaches the origin. When the details leaked, these existing protections were already blocking the command-execution payloads carried inside exploit requests, such as shell commands and download-and-run instructions.

• Emergency rule update (October 21): Security experts analyzed the PHP advisory, public PoCs and early attack traffic. The team then released new rules that block the exploitation path itself, regardless of the payload an attacker uses. These rules block known exploit tools and abuse of the session upload progress field. They also block session IDs sent in the request body and malicious PHPSESSID values. The update adds monitoring of upload progress activity to detect new attack variants.

• Threat intelligence update (October 22): The managed security team also blocked source IPs linked to PHP2Shell exploitation. New rules detect out-of-memory triggers, such as very long parameter names and oversized URL-encoded bodies. 

• Continuous monitoring: The managed security team tracks new variants and indicators and updates rules automatically as attackers change payloads. 

Recommended actions for AppTrana customers: keep applications in Block mode, enable Origin Protection so attackers cannot bypass AppTrana by going directly to your servers, and upgrade PHP.