PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Detecting unauthenticated remote code execution in PHP core

On October 21, 2026, CVE-2026-109618 and CVE-2026-109619, dubbed PHP2Shell, were fixed in two emergency releases from the PHP project. The two CVEs group four related memory-safety bugs, and both vulnerabilities have a CVSS v4.0 score of 9.2. An unauthenticated attacker can exploit them to run code on a PHP server with HTTP requests alone. Multiple working proof-of-concept (PoC) exploits are circulating, and the researchers who reported the vulnerabilities said AI models helped in both discovery and exploit development. 

Researchers reported the bugs to PHP in August 2026, PHP started a coordinated fix in September, and coordinated disclosure was set for October 22. Then, on October 20, the CVE identifiers and exploit details leaked to Hacker News and social media. PHP published an advance notice the same day and moved the release forward by one day, to October 21 at 14:00 UTC. 

Exploitation did not wait for the patch. Amazon Threat Intelligence saw a PHP2Shell attempt against its MadPot honeypots on October 17, four days before disclosure. Cloudflare reported early attacks on October 21 at 07:43 UTC, more than six hours before the fix shipped. watchTowr reproduced the bugs and reported active exploitation attempts against each.

The vulnerable code dates back to PHP 5.4, released in 2012. The bugs live in the PHP engine, not within any application. For that reason, any WordPress, Drupal, or Joomla site with clean application code is still exposed.

To provide additional recommendations for security teams and create runtime detection coverage for Sysdig Secure and open source Falco users, the Sysdig Threat Research Team (TRT) analyzed PHP2Shell exploitation. The findings are outlined below.

Affected PHP versions

In addition to the version number, there are three additional factors to consider for potential exposure to PHP2Shell: 

• Distribution packages: Linux distributions and LTS vendors received the patches before release. Vendors often backport fixes without changing the upstream version number, so check the vendor advisory and not only php -v. Any package reporting an old version should be patched.
• Affected SAPIs: Every PHP installation that serves web requests. This includes Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. PHP rates mod_php as the highest risk. A SAPI is how PHP connects to a web server, so if PHP answers HTTP requests in any form, it is in scope. 
• Default configuration: Vulnerable. There are no specific settings needed to be exposed.

Root cause

A PHP worker reuses its memory from one request to another. When a request goes over memory_limit, PHP hits a fatal out-of-memory error and destroys the request heap. The worker survives, and continues to the next request. 

The flaw is that PHP does not clear global pointers into the request heap after a fatal out-of-memory error, so a later request on the same worker uses stale pointers into freed memory. All four bugs share this root cause. 

CVE-2026-109618: Session upload progress

• Use-after-free in the unserializer. Session upload progress decodes session data while PHP parses a multipart/form-data upload. It keeps bookkeeping in the unserializer's global state. An out-of-memory error destroys the request heap, but this global state stays published.
• Remote memory disclosure. Upload progress also stores the session ID in a global pointer. An out-of-memory error can leave that pointer dangling. A later multipart request on the same worker reaches the upload-progress cleanup before session initialization resets the pointer. PHP then URL-encodes the reclaimed heap contents into the PHPSESSID response cookie and sends them to the client.

Session upload progress is enabled by default. It runs during request parsing, before any application code, and even if the application never calls session_start(). Authentication and application filters do not stop it.

CVE-2026-109619: Fatal-error backtrace and OPcache

• Use-after-free in fatal-error backtraces. PHP keeps the backtrace of the last fatal error in a global. An out-of-memory error destroys the request heap but does not clear that global. The next request on the worker finds a pointer into the previous request's memory.
• OPcache type confusion. While OPcache persists a compiled script to shared memory, an allocation failure at the wrong moment leaves internal slots inconsistent across workers. One worker then interprets data with the wrong type.

Impact

PHP2Shell is a pair of unauthenticated remote code execution flaws in the PHP engine itself. Because they sit below the application and trigger before any application code runs, the exposure is every internet-facing PHP server on an affected version, and the impact ranges from silent theft of other users’ secrets to full code execution on the workload, with a path onward to the host. 

• Unauthenticated remote code execution, no credentials. Any client that can send HTTP requests to a vulnerable PHP server can run code as the web-server user. No login, application bug, or user action is needed.
• Exposure of every PHP application, not just popular or common ones. The bugs are in the engine, so even a minimal application on an affected PHP version can be vulnerable.
• Leaked secrets from other users’ requests. The memory disclosure works on its own, without RCE. It returns freed process memory to an unauthenticated client. That memory can hold data from other requests the same worker handled: credentials, session tokens, API keys, and even TLS private keys. 
• Container compromise and a path to the host. A PHP container is a common internet-facing workload. Code execution there gives the attacker the container's service account, mounted secrets, and network position. From there, a kernel LPE such as Copy Fail or Dirty Frag can lead to the host.

Detecting PHP2Shell with Sysdig Secure

Sysdig Secure customers using managed policies have detections to help them identify and respond to this active threat. The Sysdig TRT has already published a Threat Intelligence entry for PHP2Shell in Sysdig Secure, and Sysdig vulnerability management detects vulnerable PHP versions across images and hosts. Existing runtime detection rules also cover post-exploitation activity. 

Threat intelligence

Sysdig Secure customers already have a PHP2Shell entry in the Threat Intelligence feed. The entry summarizes the flaw, the fixed versions, and the interim mitigations. It also shows how many hosts and workloads in your environment are impacted. Select the count to open a filtered search of the affected asset.

Vulnerability management

Sysdig vulnerability management detects CVE-2026-109618 and CVE-2026-109619 across your environment:

• Images: Pipeline and registry scanning flag images that ship a vulnerable PHP runtime installed through the OS package manager, before they reach production.
• Runtime workloads and hosts: Running workloads and hosts are matched against the new CVEs automatically. No rescan is needed.
• Distribution backports: Matching uses vendor advisories, so a patched distribution package is not reported as vulnerable only because of its upstream version number.
• Prioritization: Filter on workloads where the PHP package is in use, and start with internet-facing ones.

Runtime detection

The Sysdig TRT built two layered runtime rules for PHP2Shell and validated them against a working exploit. They ship as managed rules in the Sysdig Runtime Behavioral Analytics and Sysdig Runtime Notable Events policies. The two rules are PHP Web Worker Killed by Fatal Signal and PHP Web Worker Crash Followed by Shell Execution.

A successful PHP2Shell attack gives the attacker a command line, and from there attackers do what they do after any web RCE. They open a reverse shell, download and run a tool, start a miner, steal cloud credentials, or try a kernel LPE to get root. Sysdig Secure already detects this post-exploitation activity with managed rules in the policies that are enabled by default. Most of these rules match the behavior, not the parent process, so they work the same way whatever PHP runtime serves the application. 

Detecting PHP2Shell with open source Falco

Falco sees syscalls, not HTTP requests. It cannot see the malicious request itself, but it can see what the request causes on the host. There are many possible detection strategies, such as detecting shell processes from php workers, but noise often poses a major challenge. As we showed before with Sysdig Secure, many existing post-exploitation detection strategies apply.

Recommendations

• Update PHP on every server: Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to a vendor-patched package. This is the only complete fix. Application code cannot fix this.
• Restart every PHP worker after you patch: Old workers keep running the vulnerable code.
• Mitigate with the interim settings if you cannot patch today: PHP states that these settings reduce the risk but do not remove it:
  
  • Set memory_limit=-1 through php_admin_value, so applications cannot override it. Enforce request size limits at the web server or proxy instead. Do not use RLIMIT_AS or RLIMIT_DATA.
  • Set session.upload_progress.enabled=0 in php.ini or the FPM pool config. Do not rely on ini_set() or .user.ini.
  • On PHP 8.5, also set fatal_error_backtraces=0.
  • Restart every worker, and verify the values through a web request, not the CLI.‍
• Block multipart/form-data at the edge if uploads are not needed: This blocks the session upload-progress path and the memory disclosure. It does not cover every bug, and it breaks file uploads and some checkout forms.
• ‍Audit your environment: Find every affected host and workload, and start with internet-facing ones. Sysdig Secure customers can use the Threat Intelligence entry and Vulnerability Management findings. ‍
• Investigate dating back to October 17: Exploitation began before disclosure. Check for web shells, new cron jobs, new accounts, and shells spawned by web server processes.‍
• Rotate secrets: Because of the memory disclosure, even if you see no sign of code execution, secrets should be rotated for exposed servers.‍
• Enable default runtime policies: Use detections for post-exploitation behavior such as known threats, threat intelligence matches, and behavioral anomalies. For internet-facing web applications, alert on shells and suspicious commands spawned by the web server. The Sysdig Runtime Threat Detection, Sysdig Runtime Threat Intelligence, and Sysdig Runtime Behavioral Analytics policies catch the post-exploitation stage. For internet-facing PHP, customers should also enable the Sysdig Runtime Notable Events policy, or at least its rules for shells and suspicious commands spawned by web servers.

Conclusion

PHP2Shell is composed of four memory-safety bugs under two critical CVEs in PHP core, the most widely deployed web runtime. Exploitation began before the fix existed, and PHP has carried the vulnerable code since 2012.

It is the third high-impact flaw this year in old, widely trusted core code, following Copy Fail and Dirty Frag. Like those vulnerabilities, PHP2Shell was found with AI assistance. Defenders should approach these vulnerabilities with an “assume breach” mindset, as exploitation can begin before a patch exists. Patch first. Then, until every worker is patched and restarted, use the interim settings, edge filtering, and runtime detection to close the gap.

‍