PHP2Shell (CVE-2026-109618, CVE-2026-109619): Technical Analysis and CISO Action Plan

CISO Platform Intelligence · Vulnerabilities & Patching · Updated Oct 29, 2026

TL;DR

PHP2Shell is two flaws in PHP, CVE-2026-109618 and CVE-2026-109619, each scored CVSS v4.0 9.2. Both allow remote code execution without logging in. PHP fixed them on Oct 21, 2026, CISA added both to KEV on Oct 26, and the US federal (FCEB) deadline is Oct 29.
Exploitation has been confirmed on honeypots in a deliberately favourable setup. How well the attack works against real production servers is still unclear. No public source has named who was breached or who is behind the attacks.
The most urgent risk may be PHP running inside vendor appliances, not only your own web servers. Palo Alto Networks PAN-OS/Panorama (no fix yet) and Cisco Expressway are both affected.

What happened

Date (2026)	Event
Aug 19 / Aug 24	Wiz finds the first bug, then reports it to PHP
Sep 21	PHP acknowledges the report
Oct 17	Amazon threat intelligence sees the first exploit attempts against a honeypot, four days before public disclosure
Oct 20	Details leak before coordinated disclosure. PHP issues an advance notice and CERT-EU publishes Advisory 2026-018
Oct 21	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35
Oct 23	PHP discloses a separate session flaw, CVE-2026-115560. Palo Alto Networks Unit 42 links an intrusion at a European government agency to PHP2Shell
Oct 24	Adel Karimi (Perplexity) reports successful RCE on honeypots running PHP 8.4.26
Oct 25/26	Unit 42 retracts the European government agency claim (sources give both dates)
Oct 26	CISA adds both CVEs to KEV. PHP for Windows ships builds fixing the Brotli flaw
Oct 27	SOCRadar reports a weaponized PHP2Shell toolkit on an extortion operator's server, tied to about 20 Japanese real-estate sites
Oct 29	FCEB remediation deadline

Technical analysis

CVE-2026-109618 (out-of-memory corruption). If PHP runs out of memory partway through setting up a request, cleanup code can treat the half-built data as valid. That can be exploited for RCE.

CVE-2026-109619 (stale request state). Internal state tied to one request can outlive the memory it points to after that memory is freed. A later request on the same worker can then use it before it is reset.

Wiz says four underlying bugs sit behind the two CVEs, all in how PHP handles fatal out-of-memory errors mid-request. Wiz also showed that attackers can read PHP worker memory, which can hold passwords and API keys, and demonstrated code execution without authentication on out-of-the-box WordPress, Drupal and Joomla.

Affected: every PHP install serving web requests before the fixes, including end-of-life branches. Fixed upstream: 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, 8.2 before 8.2.35. PHP published minimal source backports for 8.1, 8.0 and 7.4 (for people who build from source). 7.3 and older get no fix from PHP.
Server setups: Apache mod_php carries the highest risk. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also at risk.
Exploit preconditions in the tooling SOCRadar analysed: PHP errors visible, upload progress enabled, strict mode off, a very low memory limit and a single Apache worker. The tooling leaks session cookies to defeat ASLR. Karimi says his single-worker honeypots favoured the exploit and do not show how reliable it is elsewhere.
Is it really being exploited? Sources disagree. PHP says the public PoCs it reviewed did not work. Tenable cites reports of working exploits against PHP 8.2 through 8.5. Karimi's activity matched CVE-2026-109618 only. Sophos withdrew its first assessment after finding only scanning and failed attempts.
Related flaw, "Broccoli2Shell" (CVE-2026-111497): an out-of-bounds write in the Brotli decoder (1.0.3–1.0.9, 1.1.0 and 1.2.0; fixed in 1.0.10, 1.1.1 and 1.2.1). In PHP on Windows it is reachable through the cURL extension when automatic response decompression is on, which is off by default but libraries can enable. Fixed PHP for Windows builds: 8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1. Node.js, Bun, Envoy, Istio, .NET and Python were also patched.
Session flaw CVE-2026-115560 (Oct 23): not yet patched or scored, no exploitation reported. It only affects apps that switch session.serialize_handler to php via ini_set() before session_start() while upload progress is on.

Why it happened

The flaws sit in PHP's error-recovery and per-request reset logic. A fatal out-of-memory error can leave state half-built or still pointing at freed memory, and worker reuse lets a later request reach it. Disclosure then went badly: details leaked a day before coordinated release, and attempts began before patches existed. Wiz says frontier AI models helped find the bugs and build the exploits.

Who is affected / exposure

Exposed population (estimates differ by method): Censys counts more than 32.51 million PHP services on an affected version (via The Hacker News). SOCRadar tracks about 5.1 million exposed PHP hosts. Shodan shows about 884,000 hosts on PHP 8.1 or older, plus about 740,000 showing PHP with no version.
Attack volume (Delft University Threat Intelligence Lab, via The Register): more than 50,000 exploit requests from more than 600 IPs in 70 countries; 171 of those IPs sent exploit code or malware droppers.
Karimi honeypots: 35 successful shell executions from two IPs. Follow-on downloads via PHP, curl and wget failed.
Not publicly known: who the victims are, how many production systems were breached, and who the attackers are. Varied payloads suggest more than one actor.

How it affects CISOs

Breach exposure: RCE without login on internet-facing PHP means possible data breach and loss of secrets held in worker memory (passwords, API keys).
Appliances you cannot patch yourself: PAN-OS 12.2, 12.1, 11.2, 11.1 and 10.2 and all Panorama versions are affected with no fixed release yet. Cisco Expressway is fixed in 15.5.21 with no workaround. Cisco Ultra-Reliable Wireless Backhaul is affected. Fortinet and Splunk products are under investigation.
Version checks can mislead: vendor backports may fix the flaw without changing the version number, and php -v may report a different PHP install than the one actually serving web traffic.

What to do

Immediate (24h)

Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply your vendor's backported fix. Apply the -1 builds on Windows.
Isolate or take offline systems that cannot be patched (CERT-EU and UK NCSC guidance).
Block 206.188.197.105 at the perimeter and search past logs for it (SOCRadar).

Interim mitigations (not a substitute for patching)

session.upload_progress.enabled=0, then restart all workers. This alone is not enough.
Lower post_max_size and enforce request size and count limits at the proxy; use cgroup or container memory limits.
On PHP 8.5, set fatal_error_backtraces=0; set expose_php=Off.
Vendor signatures: Palo Alto Threat Prevention IDs 543004 and 97622–97625 (plus restricting management access); Cisco Snort rules 67359 and 67360.

This week: hunt (SOCRadar indicators)

Review logs from Oct 17 onward, not just from the patch date.
Request signals: multipart POSTs containing PHP_SESSION_UPLOAD_PROGRESS, especially uploads named MARKER_ plus eight hex characters; oversized or malformed PHPSESSID cookies; session ID prefixes fprint and dp; memory-limit errors and bursts of HTTP 500s.
Process signals: php-fpm, php-cgi, httpd or apache2 spawning shells, interpreters, or curl/wget.
If something fires: isolate the server, keep the logs, and look for web shells, new web-root files, new cron jobs and new accounts.

Strategic

Retire PHP 7.3 and older. Keep an inventory of PHP embedded in vendor products.
Treat WAF rules as a stopgap only. Plan for leaks that come before coordinated disclosure.

Questions to ask your team / vendors

Which internet-facing hosts run PHP, under which setup (mod_php, FPM, CGI, FrankenPHP, LiteSpeed), and how did we confirm which binary actually serves traffic?
Do we run end-of-life PHP branches? What is the exit plan?
Vendors: does your product embed PHP or Brotli? What is the fixed build, and if you backported, how do we verify it?
Have we hunted back to Oct 17 for the indicators above? What did we find?
Does any app use the CVE-2026-115560 session pattern, or enable cURL automatic decompression on Windows?

Sources

Discuss: How are you confirming fixes in vendor appliances that ship backported PHP when the version number does not change?

Hunting PHP2Shell in vendor appliances you can’t patch yourself?

Security leaders on CISO Platform are comparing which vendors have shipped verified fixes, and how they are confirming backports. Join to see the discussion and add what you’ve found.

Join CISO Platform (free for security leaders) →

All Articles