CVE-2026-109618 and CVE-2026-109619: CISA Adds PHP2Shell to KEV After Confirmed Attacks

CISA added CVE-2026-109618 and CVE-2026-109619, the two PHP flaws known as PHP2Shell, to its Known Exploited Vulnerabilities catalog on Monday, October 26, 2026, with a federal due date of October 29, according to VulnTracker and THN. PHP patched both on October 21, and the week since has changed what they are. A researcher at Perplexity confirmed code execution against a live honeypot on October 24, public exploit code is circulating, and vendors such as Palo Alto Networks and Siemens are shipping fixes for products that embed PHP. This post separates what is confirmed from what is not, and lists what to do before the deadline.

What is confirmed, and what is not

Exploitation attempts came first. Amazon's MadPot honeypots logged one on October 17, four days before the patches, and Cloudflare later reported millions of attempts after disclosure. Through most of the week the picture stayed murky. TRACE at Dataminr described scanning, fingerprinting and exploits that did not work, with no known compromises.

The first solid confirmation came on October 24, when Adel Karimi, who leads detection and response at Perplexity, reported successful remote code execution against honeypots. The target was an Apache mod_php install running PHP 8.4.26. The response carried an 800 KiB decoded cookie dump, a function address derived from that dump appeared in the next payload, and the honeypot then ran php, curl and wget commands fetching a file from 162.35.99.94. No second-stage tooling has been seen. Karimi added a caveat of his own: the result says nothing about exploit reliability on other worker counts, PHP builds or applications. Marcus Hutchins of Expel called it the best confirmation of in-the-wild PHP2Shell exploitation he had seen.

Public code followed. Akatsuki Legion, an adversary research group, credits an exploit chain to a researcher known as 9bie and says AI-generated proof-of-concept scripts appeared on GitHub right after the October 21 release. On October 25 a researcher called killa won a public Bitcoin challenge, worth about $2,021, by exploiting an unpatched PHP site over 19.28 hours, then published a proof of concept. It uses two memory leaks and then a forged structure that makes PHP call its system function. By the author's own account it worked in about seven of ten lab runs, and the live request was not fully captured.

Some claims did not hold up. THN's October 25 story linked an attack on a European government entity to PHP2Shell, and Unit 42 later said it could not confirm that the initial access involved these CVEs. Other activity is attributed with less certainty than the headlines suggest: Sophos studied a blocked payload that looked like a Mirai variant and found no proof of compromise, and CYFIRMA assesses, with moderate confidence, low-volume probing from a suspected North Korea-linked operator.

How the flaws work and who is affected

Both bugs come from how PHP handles requests that end badly. CVE-2026-109618 starts when PHP runs out of memory. PHP uses longjmp() to abort the request, and in some contexts request memory is reachable before it is fully initialized, so the cleanup step reads or branches on invalid data. Oversized or oddly built multipart requests can reach that state within post_max_size. CVE-2026-109619 is stale global state: after a fatal error, error, session or object state can still point into freed request memory, and a later operation uses it. PHP confirmed two paths, INI diagnostics before request initialization and session upload progress, plus a fatal-error backtrace path on PHP 8.5. Session upload progress is enabled by default. PHP's advisories say the confirmed impact of both is unauthenticated code execution as the web worker account. Validation was against mod_php, and PHP states that no complete FPM exploit has been demonstrated for CVE-2026-109618, although the session path was validated on FPM for CVE-2026-109619.

PHP fixed both in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21. PHP's own advisories list affected ranges below those versions with no lower bound, Wiz says the code goes back to PHP 5.4, and VulnTracker's PHP entry starts at 7.3.0. PHP 8.1 and older no longer receive updates from the project, so check whether your distribution ships a backport. THN cites Censys estimating more than 32.51 million PHP services still running an affected version.

The flaw also sits inside products. Palo Alto Networks says the PAN-OS management web interface and XML API on PA-Series and VM-Series firewalls and on Panorama are affected, with no special configuration needed. GlobalProtect and Captive Portal are not. As of its October 26 update, Palo Alto says it is not aware of malicious exploitation against its products, and hotfix release dates run through October 30. Siemens lists RUGGEDCOM APE1808 devices running PAN-OS 10.2 through 12.2 in advisory SSA-566512 and says to contact support for patch information. The THN KEV article lists advisories from dozens more vendors, among them ABB, Arista, Broadcom, Citrix, Dell, F5, HPE, Ivanti, QNAP, Synology and WordPress.

Two other PHP issues share the news cycle and are separate. CVE-2026-115560 is the conditional session-handler issue PHP is fixing in a later release. CVE-2026-111497 is a Brotli decoder bug, also called Brotli2Shell, for which PHP rebuilt its Windows packages on October 26.

Confirmed is narrow, KEV is broad

The evidence behind the KEV listing is narrower than the listing itself. The clean confirmation is one honeypot, one worker profile, one PHP build. The public proof of concept worked in about seven of ten lab runs. PHP says a full FPM exploit has not been shown for CVE-2026-109618. And the highest-profile attack story, the European government entity, lost its link to these CVEs after Unit 42 stepped back.

CISA still gave federal agencies three days. That is the useful signal for a defender: the catalog is built on evidence that exploitation is happening, not on proof that every deployment can be taken over. The gap changes the order of work, not the decision to patch. Put internet-facing mod_php servers first, since that is where the confirmed attack landed, and management interfaces that embed PHP next, since an unauthenticated flaw in a firewall's web interface is a different category of exposure from a blog on shared hosting. Then work through FPM, FrankenPHP and everything else on the same patch cycle.

It also argues against waiting for a better exploit to show up. The code is public, researchers are reproducing it, and the attack surface is large.

Reading it on VulnTracker

The two records share a lot, and the places where they differ are worth reading before you triage.

	CVE-2026-109618	CVE-2026-109619
Title on VulnTracker	RCE via OOM corruption	RCE via stale global state
NVD score (CVSS 3.1)	9.8 Critical	8.1 High
PHP score (CVSS 4.0)	9.2	9.2
Palo Alto product score	8.7	8.7
EPSS	100%	100%
KEV	Added Oct 26, due Oct 29	Flagged as KEV
SSVC	No known exploit, Not automatable, Total impact	No known exploit, Not automatable, Total impact
CWE	416, 755, 824, 1325, 1419	416, 755, 824, 1325, 1419
Status	Analyzed	Analyzed

Three points matter. First, the 9.8 against 8.1 split comes from attack complexity in the 3.1 vectors, Low for one and High for the other. PHP rates both 9.2 on CVSS 4.0, and Siemens publishes the same 9.8 and 8.1 pair. Second, the SSVC exploitation field says No known exploit on both records even though they are on KEV, so the SSVC data is behind the catalog again. Go by KEV. Third, VulnTracker's affected data lists four products across three vendors, PAN-OS, the Panorama virtual appliance, PHP and RUGGEDCOM APE1808 firmware. The PHP ranges start at 7.3.0, which does not appear in PHP's advisories, so treat any PHP below the fixed versions as in scope. The remediation guide is empty for now, and the next section fills that gap.

What to do before October 29

1. Update PHP. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution build that includes the fix, and restart every worker. PHP calls the update the only complete mitigation. If you run 8.1 or older, ask your distribution or vendor for a backport, or plan the move to a supported branch.
2. Reduce exposure if you cannot update today. Set session.upload_progress.enabled=0 in php.ini or the pool configuration and restart workers. It covers the session path only and does not replace the update. PHP also describes memory_limit=-1 as its primary configuration mitigation for the out-of-memory flaw, while saying it is not complete. Block multipart requests at the frontend if the application does not use them, and avoid RLIMIT_AS or RLIMIT_DATA, which make the vulnerable path easier to trigger. On PHP 8.5, fatal_error_backtraces=0 removes one confirmed path.
3. Palo Alto PAN-OS and Panorama. Restrict management access to trusted internal addresses or a jump box. Install the hotfix for your release line as it lands (the advisory lists dates through October 30), and apply Threat Prevention signatures 543004 and 97622 to 97678 on inbound management traffic in the meantime.
4. Siemens RUGGEDCOM APE1808. Contact Siemens support for patch information and apply Palo Alto's upstream workarounds.
5. Look for signs of exploitation. Search web logs for unusual multipart POSTs followed by memory-limit errors or HTTP 500 responses, large or malformed PHPSESSID cookies, PHP_SESSION_UPLOAD_PROGRESS inside upload forms, crashing workers, and requests with the user agent php2shell-109618 or to /lib/phpunit/phpunit/Util/PHP/eval-stdin.php. Check outbound connections to 162.35.99.94, and look for php, curl or wget commands that fetch files named pwn-. Amazon notes that some probing IPs belong to shared anonymization services, so investigate those and do not rely on blocking them.
6. Rotate secrets on exposed servers. The memory disclosure path can leak data held in worker memory, such as cookies, tokens and keys. For servers that stayed unpatched through the October 24 confirmation, rotate what they held.

Takeaway

The KEV listing does not claim every PHP server can be taken over today. It says exploitation is real, the code is public and the patch has been out for six days. Order your work by exposure, with mod_php servers and firewall management interfaces first, and treat the unpatched remainder as a list with an owner and a date. Where a product bundles PHP, the fix comes from that vendor, so check its advisory instead of the PHP version number.

To follow both records as scores, affected versions and remediation guides are filled in, track CVE-2026-109618 and CVE-2026-109619 on VulnTracker.

References

• Vendor: PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), Palo Alto Networks advisory, Siemens SSA-566512
• NVD: CVE-2026-109618 and CVE-2026-109619
• Analysis: The Hacker News on the KEV listing, BleepingComputer on confirmed exploitation, The Hacker News on scanning and the government claim, Cyber Security News on public exploit code, Cyber Security News on the Bitcoin challenge, Cyber Security News on Palo Alto
• Research: Wiz, Amazon Threat Intelligence