PHP2Shell: Two Critical Vulnerabilities That Affect Every PHP Server
On 20 October 2026, details of two critical PHP runtime vulnerabilities leaked ahead of coordinated disclosure. CVE-2026-109618 and CVE-2026-109619 both score CVSS 9.2, both allow unauthenticated remote code execution, and both fire before your application code even loads. Emergency patches landed on 21 October. Attackers aren’t waiting — Amazon confirmed exploitation three days before the public disclosure. If you haven’t patched, your servers are exposed right now.
What You Need to Know Right Now
PHP2Shell is the collective name for two independent memory-safety vulnerabilities in PHP’s core runtime. They don’t care what application you run, what framework you use, or how tight your code is. They target PHP itself.
-
CVSS 9.2 — Critical. Both CVEs carry the highest severity band. Unauthenticated remote code execution, zero user interaction, full server compromise.
-
Every PHP app is a target. WordPress, Laravel, Drupal, Magento, custom apps — anything running PHP 5.4 through 8.x is vulnerable. The flaw is in PHP itself.
-
Discovered by AI audits. Security firms Calif and Wiz independently found both flaws using AI — OpenAI’s GPT-5.6 Sol and Google’s Gemini 4 Argon — during automated source code audits.
-
Exploited before disclosure. Amazon’s MadPot honeypots detected active exploitation on 17 October — three full days before the vulnerabilities went public.
-
Emergency patches available. PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 fix both flaws. Released 21 October 2026. CISA issued an advisory the same day.
-
Bypasses all app defenses. The exploit fires during PHP’s internal request handling — before your application code, authentication middleware, or WAF rules ever execute.
-
Leaks server memory. The bug can leak PHP worker memory into response cookies — passwords, session tokens, database credentials, API keys, and potentially TLS private keys.
-
Nearly invisible. CrowdStrike noted that exploitation “leaves virtually no digital traces” in application logs. The attack runs at a level most monitoring tools don’t see.
The Vulnerabilities: Two Memory-Safety Flaws in PHP’s Core Runtime
PHP2Shell isn’t a flaw in your application — it’s a flaw in PHP itself. Both bugs live
deep inside PHP’s request lifecycle and stem from its long-standing use of
longjmp() for fatal error handling. When something goes wrong mid-request, PHP jumps
execution to a recovery point, but the data structures built along the way don’t always get
cleaned up. Researchers at Calif — backed by OpenAI’s “Patch the Planet”
initiative — and Wiz (now part of Google) independently found ways to weaponize that gap for
arbitrary code execution.
CVE-2026-109618: Out-of-Memory Corruption
PHP marks internal request data structures as valid before allocating the memory to fill them. When
allocation hits the memory limit, PHP’s OOM handler bails out via longjmp() —
but those structures stay marked valid despite pointing to uninitialized heap memory. During request
cleanup, PHP processes this garbage as real data. An attacker who can trigger OOM at the right moment
controls what sits in that memory, turning it into a code execution path. Classified CWE-824 (Access of
Uninitialized Pointer). CVSS v4.0: 9.2.
CVE-2026-109619: Use-After-Free via Stale Worker State
PHP worker processes handle multiple requests in sequence. Internal state from one request should be cleared before the next, but here the memory gets freed while the pointers stick around. When the next request lands on the same worker, PHP accesses stale pointers before reinitialization kicks in. An attacker sends two crafted requests to the same worker — the first plants controlled data in memory, the second uses the dangling pointer to reach it. Classified CWE-416 (Use After Free). CVSS v4.0: 9.2.
Affected and Patched PHP Versions
Every PHP version from 5.4 through the unpatched 8.x releases is affected. Fixed versions released 21 October 2026: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 5.x and 7.x are end-of-life and didn’t get official patches, though TuxCare has published source backports for PHP 7.4, 8.0, and 8.1. If you’re on anything below PHP 8.2, your migration path is upgrading to a supported branch now.
How to Fix PHP2Shell
Patching PHP is the only real fix. No WAF rule, no config tweak, and no workaround fully protects you. Update, restart, verify.
-
Check your PHP version. Run
php -von every server, VM, and container. Anything below PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 is vulnerable and needs an immediate update. -
Patch on Debian / Ubuntu.
sudo apt update && sudo apt upgrade php— then verify the installed version withphp -v. Patched packages were published on 21 October. -
Patch on RHEL / AlmaLinux / Rocky.
sudo dnf clean metadata && sudo dnf upgrade 'php*'— pull the latest packages from your distribution’s repository and verify withphp -v. -
Patch on cPanel / Plesk / CloudLinux. Open your control panel’s PHP version manager and apply the update. CloudLinux, cPanel, and Plesk have released patched builds. Verify with
php -v. -
Restart PHP services. The patch doesn’t take effect until PHP restarts. Run
sudo systemctl restart php-fpmthensudo systemctl restart apache2(ornginx). -
Rebuild Docker containers. Pull the latest official PHP images —
php:8.4,php:8.3, etc. — and rebuild. Your running containers use the old vulnerable binary until they’re rebuilt.
How to Detect If You’ve Been Compromised
Shell processes under PHP workers. Check if php-fpm,
php-cgi, httpd, or apache2 processes have spawned child
processes like sh, bash, cmd.exe,
powershell.exe, python, perl, curl,
wget, nc, or certutil. Any of these under a web server
process tree is a strong compromise indicator.
Anomalous HTTP traffic. Watch access logs for high volumes of multipart POST requests, clusters of HTTP 500 responses, and requests from single IPs cycling through endpoints rapidly. These patterns match the exploitation sequence for both CVEs.
Recon commands under web users. Search process and audit logs for
whoami, id, uname -a, ipconfig, or
cat /etc/passwd running under www-data, apache,
nginx, or equivalent service accounts.
Reverse shell indicators. Look for outbound connections from PHP processes with
command-line strings containing /dev/tcp/, fsockopen(),
mkfifo, or base64-encoded payloads — classic signatures of reverse shell
establishment.
Oversized session cookies. The vulnerability can leak PHP worker memory into PHPSESSID response cookies. Check your logs for response cookies that are abnormally large or contain fragments of other users’ sessions, database credentials, or configuration values.
Conclusion
PHP2Shell is a runtime-level flaw that no application code, framework, or WAF can fully mitigate. The only reliable defense is updating PHP to a patched version — 8.2.35, 8.3.36, 8.4.27, or 8.5.12 — and restarting your services. With active exploitation confirmed before public disclosure and proof-of-concept code already circulating, every hour unpatched is exposure. Check your versions, apply the update, and verify.
WhatsApp