PHP2Shell: What defenders need to know about CVE-2026-109618 and CVE-2026-109619

By Trellix Advanced Research Center · October 22, 2026

What happened

On October 21, 2026, the PHP project released emergency fixes for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell. Both carry a CVSS v4.0 score of 9.2. They let an unauthenticated attacker run code on a web server, and because the flaws sit in PHP itself rather than in any application or plugin, a site can be exposed even when its own code is secure.

CVE-2026-109618 is in how PHP handles running out of memory: the request is interrupted while internal data is only partly set up, and cleanup then treats that data as valid. CVE-2026-109619 is a use after free, where request state survives after its memory is freed and is reused by a later request on the same worker. The most commonly abused trigger is a multipart POST carrying a PHP_SESSION_UPLOAD_PROGRESS field, which works against the default configuration. Note that vendors do not agree on which CVE covers that path: PHP files it under CVE-2026-109619, while several research teams label it CVE-2026-109618.

Apache with mod_php is the highest risk setup, with code execution demonstrated before any application code runs. PHP-FPM, CGI, FrankenPHP, and LiteSpeed are also affected. Researchers have demonstrated exploitation against WordPress, Drupal, and Joomla, and confirmed it against other popular platforms including Magento, Nextcloud, and phpMyAdmin.

PHP2Shell timeline

• August 2026: Researchers at Calif and Wiz, working with AI models, independently find the flaws and report them to PHP. OpenAI is credited alongside them and coordinated the disclosure with the researchers and the PHP maintainers; Quarkslab is also credited.
• October 17: Amazon Threat Intelligence records an exploitation attempt in its honeypots, four days before disclosure.
• October 20: Details leak online ahead of the coordinated release.
• October 21: PHP publishes fixed versions at about 13:34 UTC. Public proof of concept code and scanners spread within hours, and Cloudflare reports attempts growing from thousands to millions.
• October 21, afternoon: The first working payload deliveries are seen. ELLIO sensors record a Mirai botnet loader at 14:38 UTC and a PHP web shell written into a web root later that evening.
• October 22: Attackers deliver a DDoS botnet binary and a Go remote access agent, and start rotating request bodies to evade WAF rules.

How serious is P2PShell?

Exploitation attempts are confirmed at internet scale, and working payloads are being delivered. Public reporting has not yet established how many production servers have been compromised, and no ransomware group or named threat actor has been linked to PHP2Shell. The payloads seen so far are commodity: ELLIO identifies one as a Mirai variant known as Potassium, a botnet family documented by Nokia Deepfield earlier this year. In other words, existing botnet operators have added PHP2Shell as a new way to spread.

Successful exploitation can be quiet. CrowdStrike reports that the PHP worker does not crash and returns a normal HTTP 200, so application logs may show nothing. Treat secrets held in PHP worker memory on unpatched internet facing hosts, such as database passwords, API keys and session tokens, as potentially exposed.

P2PShell: What to do now

1. Patch. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, preferably through your distribution or vendor packages, then restart PHP and web server processes so the fixed runtime is actually loaded.
2. Deal with end-of-life PHP. PHP has published source-only backport branches for 7.4, 8.0 and 8.1, but nothing for older versions. VulnCheck estimates over 1.1 million internet-facing hosts run end-of-life PHP. Upgrade, use a verified vendor backport, or take the system off the internet.
3. Apply interim workarounds where patching is delayed. Set session.upload_progress.enabled = 0 at server level (php.ini, FPM pool or Apache config, not ini_set or .user.ini), and on PHP 8.5 set fatal_error_backtraces = 0. Cap request size, header count and multipart part count at the proxy or WAF. Do not use RLIMIT_AS or RLIMIT_DATA limits, which can trigger the vulnerable failure. PHP is clear that these steps reduce risk but do not remove it.
4. Hunt back to October 17, not just to the disclosure date.
5. Check third-party products and appliances that embed PHP for vendor fixes.

How to hunt for P2PShell

• Multipart POST requests carrying PHP_SESSION_UPLOAD_PROGRESS, unusually large PHPSESSID cookies, and bursts of HTTP 500 errors on upload endpoints.
• User agents containing php2shell.
• PHP error log lines with "Allowed memory size" and "exhausted" together with "Unknown on line 0", which indicate a failure during request startup rather than inside a script.
• PHP-FPM, Apache or php-cgi processes spawning shells, wget or curl; new .php files in web roots; new ELF binaries in /tmp or /dev/shm.
• Successful exploitation is verifiable by monitoring the target endpoints for specific activities, which vary by operating system.:
  • Linux: bash, dash, and sh processes spawned from php, apache2, php-fpm, php-cgi, and httpd processes.
  • Windows: cmd.exe, powershell.exe, and other Windows LOLBin processes spawned from php.exe and php-cgi.exe processes.

PHP2Shell indicators

High-confidence network indicators from public reporting (ELLIO, VulnCheck). Source IPs rotate quickly, so treat blocks as time limited and prioritise behavioral detection.

Trellix detection coverage for PHP2Shell

Trellix has shipped detection for PHP2Shell across network and endpoint, and continues to expand and tune it as the situation develops. The coverage below detects both exploitation attempts against your PHP servers and the post-exploitation behavior that follows a successful compromise. Patching remains the primary fix; these detections are compensating controls to catch and slow exploitation while you patch, and to surface hosts that may already have been hit.

Detections map to MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1505.003 (Server Software Component: Web Shell).

• Note: ENS Expert rules are being provided for customers to use to protect their environment. The rules are provided as-is, baseline-validated, consider tuning before enforcement.
• Download from here:
  • https://github.com/trellix-enterprise/ExpertRules/blob/main/TRELLIX/ACCESS_PROTECTION/T1505.003_Web_Shell_Creation_in_Web_Root_Directory.md
  • https://github.com/trellix-enterprise/ExpertRules/blob/main/TRELLIX/ACCESS_PROTECTION/T1505.003_Web_Shell_Suspicious_Process_Execution_via_Web_Server.md

A wider lesson: Patch fast, but defend in depth

PHP2Shell was found by researchers working with AI models, with OpenAI involved in the effort, in code paths that had been present for more than a decade, and went from disclosure to mass exploitation within hours. Seven or 30-day patching windows are no longer realistic for critical internet facing systems.

That is why the protection for an event like this cannot rest on any single control, and cannot wait for a confirmed working exploit before it engages. The strength of layered detection is that each mechanism covers what the others cannot, and it is active the moment the technique is understood.

The lesson is not that patching matters less; it matters more than ever. It is that when that window is measured in hours, patching has to be backed by detection that triggers on attacker behavior across the network and the endpoint at once—so that the hosts you could not patch in time are still the hosts you can see, and stop.

Sources: PHP security advisories, Amazon Threat Intelligence, Wiz Research, Calif, OpenAI, VulnCheck, ELLIO, Cloudflare, CrowdStrike, Nokia Deepfield, Sansec, CERT-EU.

Discover more Trellix threat intelligence research from the Trellix Advanced Research Center.