What happened
On October 21, 2026, the PHP project released fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on CVSS 4.0. Researchers call the pair PHP2Shell, and discovery is credited to Calif, OpenAI and Wiz. Recorded Future reports that Wiz privately reported the issues in late August and that PHP announced an out-of-band release on October 20. Before the release, the CVE details and a proof of concept leaked, and the PHP Foundation shipped the fixes earlier than planned. Amazon’s MadPot honeypot had already logged an exploit attempt on October 17, and Amazon, Cloudflare and Patchstack have since reported more attempts.
How the vulnerabilities work
Both are memory-corruption bugs in PHP’s core engine. When PHP hits a fatal condition, such as exceeding memory_limit, it abandons the request without fully unwinding, and later cleanup code trusts state that is no longer valid. CVE-2026-109618 needs one request: an oversized nested form field pushes allocation past the memory limit and leaves a stale entry that cleanup later uses. CVE-2026-109619 takes two: the first request leaves a global pointing at freed memory, and a later request on the same worker uses it. Both happen while the request is being parsed, before any application code runs, so the framework and the quality of your code make no difference. No authentication is required. CrowdStrike reports that one anonymous POST request gave a shell on an Apache mod_php worker, and that the exploit worked on x86-64 and ARM. JFrog’s analysis points to the session upload-progress feature, enabled by default, as one path in.
Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Branches 8.1 and earlier have no upstream fix, only limited source backports for 7.4, 8.0 and 8.1 or vendor builds.
Risk to organizations
CrowdStrike says every 7.x and 8.x release is affected, though exposure depends on configuration. Its testing points to a memory_limit below roughly four times post_max_size, and other researchers point to session upload progress, so do not assume defaults protect you. Exposure counts vary by method: VulnCheck counts about 2.6 million internet-facing PHP hosts, more than 700,000 of them on PHP 7.3 or older, while Palo Alto Networks’ Xpanse telemetry flagged over 22.6 million potentially vulnerable exposed instances. Treat these as a sense of scale, not exact figures. Successful exploitation can leave little behind: responses return HTTP 200 and application logs look normal. The main server-side artifact is a web server error log entry reading “Allowed memory size … exhausted” followed by “in Unknown on line 0.” Follow-on activity can include web shells, credential theft from configuration files, and lateral movement. Unit 42 notes that at least one European government took its website offline as a precaution.
What the vendors recommend
| Vendor | Recommended actions |
| CrowdStrike | Patching is the only complete fix. Until then, rely on behavioral monitoring for web shell deployment, suspicious child processes spawned by PHP or web server processes, and unexpected command execution. Falcon Exposure Management finds vulnerable PHP, including installs outside package managers (Linux sensor 7.31+, Windows 7.40+). Next-Gen SIEM adds a dashboard section and a correlation rule for memory exhaustion during request startup. |
| Microsoft | Upgrade every PHP deployment, including VMs, containers, base images and platform runtimes, starting with internet-facing workloads. Rebuild and redeploy container images, since patching the host does not patch PHP inside an image. Migrate off unsupported branches. As a stopgap, use Azure WAF custom rules; Front Door managed rule 99006001 (disabled by default, rollout expected by October 28); or an Application Gateway rewrite rule on PHPSESSID Set-Cookie headers. Microsoft says these complement patching and do not replace it. |
| Palo Alto Networks | Assess exposure and patch immediately. Cortex Xpanse (PHP Attack Surface Rule) identifies exposed devices. Next-Generation Firewall customers with Advanced Threat Prevention Plus get virtual patching under Threat ID 543004, active since 10:21 p.m. PT on October 20. Cortex Cloud and Prisma Cloud detect vulnerable PHP in code and cloud environments, and Cortex XDR, XSIAM and Cortex Cloud help catch post-exploitation activity. |
Recommended next steps
Inventory
Find every PHP install, including containers, hosting panels and appliances. php -v may not show the runtime serving requests.
Patch and restart
Move to a fixed version, restart or redeploy workers, and confirm the running runtime. Distribution packages may keep older version numbers with backports, so check the vendor advisory.
Deal with unsupported branches
On 8.1 or earlier, get a vendor backport or migrate. CISA and the UK NCSC have advised taking systems offline if they cannot be patched or protected.
Reduce exposure in the meantime
Apply WAF or virtual patching, set session.upload_progress.enabled=0, cap post_max_size, and limit request sizes at the proxy. These are partial measures, and PHP says updating is the only complete fix.
Hunt
Look for PHP or web server processes spawning shells and for the error log entry above. Start the lookback before October 20.
Respond if needed
If you find signs of compromise, start incident response and rotate credentials stored on the host.
How Echelon Risk + Cyber can help
Echelon Risk + Cyber can help you work through this across all five of our service lines. Vulnerability Management and Threat Hunting locate exposed PHP and look for signs of earlier compromise. Managed Detection + Response, Powered by CrowdStrike (Managed Security Services), watches for post-exploitation behavior. Offensive Security + Adversary Simulation can confirm that fixes and compensating controls hold. Our vCISO-led Security Team as a Service coordinates the response and reports to leadership, and Risk Advisory + GRC covers third-party and compliance exposure.