PHP2Shell Advisory

The backbone of the web has two new critical vulnerabilities.

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.

AffectedAll PHP serving web traffic: mod_php (highest risk), PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. Back to PHP 5.4
Fixed8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 7.4-8.1 have source-only backports. 7.3 and older have no official fix.
ExploitationUnverified exploit code is circulating (Tenable). Early attacks seen since Oct 21 (Cloudflare, watchTowr)
CVE IDsCVE-2026-109618 / CVE-2026-109619, CVSS v4 9.2.

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):

WordPress logoWordPress
Drupal logoDrupal
Joomla logoJoomla
Laravel logoLaravel
Symfony logoSymfony
phpMyAdmin logophpMyAdmin
Nextcloud logoNextcloud
Roundcube logoRoundcube

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) spawning sh, bash, curl, wget or nc
  • 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_PROGRESS and a PHPSESSID form field
  • PHPSESSID response cookies over 128 characters or containing %

Example (Microsoft Defender / Sentinel):

DeviceProcessEvents
| where InitiatingProcessFileName matches regex @"(?i)^(php-fpm|php-cgi|apache2|httpd)"
| where FileName in~ ("sh","bash","dash","curl","wget","nc")
| where ProcessCommandLine !has "sendmail"

How to prevent it beyond patching

  • Set session.upload_progress.enabled = 0 and memory_limit = -1 server-wide, then restart workers. Both are needed, but neither is a full fix.
  • Block multipart/form-data except 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_size to 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

Share this article