PHP2Shell (CVE-2026-109618, CVE-2026-109619, CVSS 9.2) lets an unauthenticated attacker run code on, or leak memory from, almost any server running PHP. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker.
What is PHP2Shell
PHP2Shell is the name for two critical vulnerabilities in PHP itself, the language behind nearly 70% of websites whose server-side language is known (Tenable). The flaws are in the PHP engine, not in any single app, so anything built on PHP is exposed until PHP itself is updated. Researchers have demonstrated unauthenticated code execution against all of these (Wiz, Sansec):
The vulnerability
Two CVEs covering several use-after-free bugs in the PHP engine. A request that hits a fatal error mid-request, typically out-of-memory from a crafted multipart POST, leaves freed memory behind that PHP still treats as live. The attacker’s next request to the same worker reuses it to run code, or to leak the worker’s memory in a PHPSESSID cookie.
Why it's different
- Discovery: found by security researchers at Calif, Wiz and OpenAI using AI-assisted research, leaked before the embargo, and attacked before the patch shipped (Cloudflare, Sansec).
- Impact: an unauthenticated attacker can run code on your web server as the PHP worker user, then plant a web shell, steal data and credentials, and move deeper into your network. Even without code execution, they can read worker memory that holds other users' passwords, session tokens and API keys. No login, plugin or special configuration is needed, and the attack runs before your app's own defenses ever see the request.
- Finding exposure: version banners are often hidden, so banner-based scans may miss exposed hosts. For comprehensive coverage, complement external scanning with internal vulnerability management.
How to detect if I was exploited
Hunt from Oct 20, 2026:
- A PHP worker (
php-fpm,apache2,httpd,php-cgi) spawningsh,bash,curl,wgetornc - PHP errors with “Allowed memory size … exhausted … in Unknown on line 0”
- Bursts of worker crashes: “exited on signal 11” (FPM), “AH00052” (Apache)
- Multipart POSTs carrying both
PHP_SESSION_UPLOAD_PROGRESSand aPHPSESSIDform field PHPSESSIDresponse cookies over 128 characters or containing%
Example (Microsoft Defender / Sentinel):
How to prevent it beyond patching
- Set
session.upload_progress.enabled = 0andmemory_limit = -1server-wide, then restart workers. Both are needed, but neither is a full fix. - Block
multipart/form-dataexcept on routes that accept uploads, enable your WAF's managed rules, and allow traffic to your origin servers only from your CDN. - Take end-of-life PHP off the internet, or put it behind a VPN if possible.
- After patching, purge session files and rotate secrets on exposed hosts.
- Lower
post_max_sizeto 8M, or 32M if you need uploads.
Controls that would have stopped it
- External asset discovery: know every internet-facing host running PHP before a CVE drops.
- No end-of-life runtimes exposed to the internet.
- Minimal unauthenticated attack surface: admin and legacy apps behind SSO or a VPN, and uploads allowed only where needed.
- Runtime detection and default-deny egress on web servers, so an unknown RCE gets caught and can't call home.
- A WAF in blocking mode in front of every internet-facing app, with origins reachable only through it, so the vendor rules shipped on day 0 actually protect you.
- Continuous offensive testing that proves exploitability, instead of trusting version banners.
How A Security can help
A Security's new Continuous External Infrastructure Testing module keeps mapping your internet-facing assets. When a new CVE is published, it automatically scans those assets for it. For PHP2Shell, it finds where you run PHP and safely validates which assets are exploitable. We're offering a free PHP2Shell exposure assessment as part of our POV process. Contact us at research@a.security or through our form here.
References
PHP advisory · GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp · Wiz
