Palo Alto Confirms PHP2Shell Attacks on Exposed PAN-OS Management Interfaces, and Dream Says an Attacker Chained It With Fragnesia to Root 25 Devices

Palo Alto Networks says the PHP2Shell flaws are being exploited against PAN-OS management interfaces that are exposed to the internet, and the security firm Dream says one attacker used them to take over 24 PAN-OS firewalls and an internal management server on October 23 and 24. When we read Palo Alto’s advisory at 19:35 UTC on Thursday, October 29, it rated the issue Critical (CVSS 4.0 score 9.2) with Highest urgency and exploit maturity Attacked. Dream’s earlier text, as the Internet Archive saved it on October 28, described the victims only as running “a large vendor’s” firewall software. An update stamped 18:02 UTC today names PAN-OS, and Palo Alto’s Unit 42 says it “independently verified the same attacker’s tooling and confirmed the reported results.”

The timing is the sharp edge. Dream’s timeline has its first rooted firewall at 18:14 UTC on October 23, two days after Palo Alto published its advisory. The last Internet Archive capture of that advisory before then, taken at 16:40 UTC, 93 minutes earlier, said Palo Alto was “not aware of any malicious exploitation,” rated the urgency Moderate, scored the impact on the product as availability only (8.7), and gave every fixed build a release estimate of October 26 or later. The kernel half of the chain, a flaw called Fragnesia (CVE-2026-46300), has had a public exploit since May 13 and an upstream fix since May. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on Wednesday, October 28, with a federal due date of Saturday, October 31, and wrote that it “can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root.”

That changes what we reported on October 21. Our report on PHP’s fix release said attempts were well documented and a confirmed compromise was not. Dream’s report, which Unit 42 says it verified, describes one, and it names the product. Both have an interest: Dream markets the research platform it says it used, and Palo Alto is the vendor whose products were hit. We say below where we could check a claim against another record and where we could not.

What happened, in order

Times are UTC. The advisory states below come from Palo Alto’s page today and from Internet Archive captures of it. The Internet Archive’s index lists no capture of that page between October 23 at 16:40 and October 27 at 17:10, so changes in that gap cannot be dated.

How Palo Alto’s advisory changed

Four Internet Archive captures of the advisory, from 04:02 and 16:40 on October 23, 17:10 on October 27 and 07:45 on October 29, plus the page as we read it, show how the vendor’s own assessment moved.

Palo Alto’s timeline records the severity change at 16:40 UTC on October 27 and nothing about the exploitation line, so we cannot date the move from “not aware” to “very limited exploitation.” The advisory also now lists 25 Threat IDs for customers with a Threat Prevention subscription, against five in the October 23 captures (our count). The advisory does not say why the scoring changed.

Is your firewall affected, and which builds fix it?

Palo Alto says the issue “strictly affects the management web interface, which includes the HTTPS web UI and XML API service,” and that it reaches a data-plane interface only if a management profile is attached to it. The advisory applies to PAN-OS on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series). Palo Alto says the GlobalProtect portal, gateway and Clientless VPN are not impacted, and neither is the captive portal. It lists Prisma Access and Cloud NGFW among unaffected products, and it says CVE-2026-115560, a later PHP flaw, has no impact on PAN-OS. Unit 42 adds that “By default the management interface is not exposed to the internet per security best practices” and tells customers to “immediately remove public internet access to management interfaces if it is enabled.”

The advisory lists 20 fixed builds across five branches. Nineteen have shipped; the one still pending is 11.1.7-h12 (estimate October 30), and the advisory also lets 11.1.7 customers move to 11.1.16-h4.

Recorded as released is the time Palo Alto’s advisory timeline says it removed a build’s release estimate, so it is a latest-possible date, not a release time. Read that way, no 12.x fix is recorded until 04:03 UTC on October 27, about three and a half days after Dream’s first rooted firewall, and the last two 12.1 fixes are recorded on October 29. Palo Alto kept to the estimates it published on October 23: 18 of the 19 shipped builds were recorded by their estimated date (the estimates carry no time zone), most of them early. The exception is 11.2.13-h4, estimated for October 27 and recorded at 05:15 UTC on October 28. The advisory’s FAQ says the same hotfix covers the PHP flaws and a Brotli flaw in the library Node.js uses, which appears to be the one we covered on October 26 (the FAQ gives no CVE ID), except that 11.2.10-h16 carries only the PHP fix and 11.2.10-h17 carries both.

How the two flaws fit together

PHP2Shell is the pair of PHP memory-corruption flaws we covered before and after PHP’s fix release. Dream says the PHP2Shell build it recovered is a custom, non-public implementation written for PAN-OS, and that it runs commands as the unprivileged user nobody. That is code execution, not control of the box. Fragnesia supplies the missing step.

Fragnesia is a flaw in the Linux kernel code that handles IPsec ESP traffic carried over TCP. The kernel fix describes the cause: when TCP receive coalescing moves shared fragments into an unmarked buffer, ESP “can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags.” In practice a local user can write into the page cache, the kernel’s in-memory copy of files, for files they can only read. Red Hat rates it Important rather than Critical “because exploitation requires local access to the system.” PHP2Shell supplies that local access remotely, which is what chaining means. V12 said its demonstration change “is not backed to disk; the on-disk binary is untouched.” Our reading: a reboot would clear a change like that, but not the webshell, tunnel service and boot hook Dream says were also planted.

The upstream fix is more than five months old. V12 published Fragnesia and a working exploit on May 13. The mainline fix was authored the same day and committed on May 15, and seven stable backports landed on May 23, when the CVE record was published. NVD lists the fixed upstream releases as 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10, and scores it 7.8 (local, low privileges). Red Hat carries the same score. CISA’s KEV entry arrived 168 days after disclosure, and like the two PHP entries it is flagged for forensic triage. V12 calls it “a member of the Dirty Frag vulnerability class,” and the same shared-fragment flag is behind the skb_zerocopy report in our October 23 report.

What Dream says the attacker did

• The funnel. A search on FOFA, a Chinese internet search engine, found about 19,000 internet-facing PAN-OS firewalls. About 5,000 answered a version scan, and 240 in the United States, Japan, Taiwan and South Korea ran the 12.1 and 12.2 branches with PHP 8.0.30. Dream says 24 firewalls were rooted, about 10 percent of 240 by our arithmetic.
• Parked devices. On 22 of the 24 the attacker did nothing beyond planting a 103-byte PHP root webshell in a publicly accessible directory, /unauth/php/change_password.php.
• The government-affiliated network. Two of the 24 firewalls and the internal firewall management server, the 25th device, belonged to one US government-affiliated organization. Dream says the attacker built a reverse SSH tunnel that forwarded eight internal ports, installed a systemd service and an rc.local hook launching scripts from /usr/local/lib/.panops/, decrypted the LDAP service account password from the device configuration, enumerated the directory, sprayed passwords against a domain with no account lockout, and tried to create backdoor user and machine accounts and to extract SAML signing keys.
• What Dream could not see. Dream says it “cannot determine” the full extent of the compromise, because the results of the spray, the backdoor accounts and the SAML key attempt stayed on the management server and were not among the artifacts it recovered. It lists harvested HA replication keys, TLS certificate keys and device authentication keys among what the attacker holds.
• AI tooling. Dream found Claude Code installed, an offensive security platform called aiscan configured with the DeepSeek and Kimi models, and FOFA API keys. It has “no direct evidence that the AI tools were specifically used to write the exploit or the post-exploitation scripts” and says the operation “does not appear to be a fully autonomous nation-state attack.” We covered two other cases of AI agents in attack tooling, ARTEX and Cairn.
• Attribution. Dream says “We do not attribute this activity to a named threat actor” and lists Chinese-nexus indicators: the target countries, FOFA, a Chinese tunneling tool, the Chinese models, UTC+8 timestamps and Chinese-language prompts.

Where the accounts differ

• GlobalProtect. Dream’s summary says the management web server “also fronts the GlobalProtect portal.” Palo Alto’s FAQ says the GlobalProtect portal, gateway and Clientless VPN are not impacted. Palo Alto’s statement is the vendor’s statement of impact, and we could not test either claim.
• How many devices. Palo Alto says “less than .01%” of its global installed base has internet-facing management interfaces configured and that each such customer was contacted. Dream counts about 19,000 internet-facing PAN-OS firewalls with exposed management interfaces. If both described the same devices, Palo Alto’s installed base would have to exceed 190 million (19,000 divided by 0.0001, our arithmetic), so they most likely count different things, and neither company defines its base. Unit 42’s figure of over 22.6 million exposed instances counts every PHP instance Cortex Xpanse sees, not PAN-OS devices.
• Whether patching breaks the whole chain. Unit 42 says the fixes “interrupt the observed exploit chain.” That describes the PHP step. Palo Alto’s security portal had no entry for CVE-2026-46300 at 19:35 UTC (its JSON endpoint answered “no such entry”), and neither the advisory nor Unit 42 says whether any PAN-OS build carries the May kernel fix.
• Which PHP. Dream says PAN-OS 12.x ships PHP 8.0.30, and its 11.1 profiles used PHP 7.4.33. PHP’s own October 21 releases covered 8.2 to 8.5, while 7.4, 8.0 and 8.1 got only source backports, as we reported. A fix for such a build therefore comes from a backport, and neither Palo Alto nor Unit 42 says which source it used.
• Who is behind it. Dream says Unit 42 tracks the activity as CL-UNK-1280 and ties it to a Chinese-speaking attacker in the UTC+8 time zone. The Unit 42 threat brief we read does not contain that name, and Unit 42 retracted an earlier PHP2Shell-linked claim on October 25, so we attribute the label to Dream alone.
• Earlier coverage. Reports written before the 18:00 UTC updates, including BleepingComputer’s, describe servers without a vendor, because Dream had withheld it. CISA lists the PHP flaws under PHP, and the KEV feed we read has no Palo Alto entry added since October 20.

What defenders can do now

• Find every management path. On each PAN-OS firewall and Panorama appliance, list the interfaces that accept management traffic: the dedicated management port and any data-plane interface with a management profile attached. Palo Alto’s guidance is to remove public internet access and allow only trusted internal addresses.
• Restrict first, then patch. The advisory scores the case where only a jump box can reach the management interface at 7.7 (5.2 with threat metrics), against 9.2 when the interface is reachable from the internet.
• Upgrade to the first fixed build for your branch from the table above. For 11.1.7, 11.1.16-h4 is listed as an alternative until 11.1.7-h12 ships, and on 11.2.10 the FAQ points to 11.2.10-h17 for the Brotli fix as well.
• If you cannot upgrade today, Palo Alto says its Threat IDs protect only if you route management traffic through a data-plane port, replace the certificate for inbound management traffic, decrypt that traffic, and enable threat prevention on it.
• Look for what Dream found before you trust the patch. Check for a small PHP file at /unauth/php/change_password.php, scripts under /usr/local/lib/.panops/ started by a systemd service or an rc.local entry, and outbound reverse SSH connections from the firewall. Unit 42 publishes Cortex XDR hunting queries for command execution under PHP worker processes; it says they are not specific to these CVEs and can produce false positives.
• Treat past exposure as possible compromise. A patch does not remove a webshell or a tunnel, and CISA marks all three KEV entries for forensic triage, which under its BOD 26-04 means federal agencies must check whether a system was compromised before it was patched. Our inference, not vendor guidance: for a firewall whose management interface was reachable from the internet at any point after October 21, plan for a rebuild rather than a patch, and rotate the secrets Dream says were taken, including the LDAP bind account and the HA, TLS and device keys.
• Patch Linux hosts outside PAN-OS too. Move to a kernel with the Fragnesia fix from your vendor’s errata, or use your vendor’s mitigation procedure if you cannot reboot; Red Hat’s CVE page points to a security bulletin for it. Federal agencies’ KEV due dates are today, October 29, for the PHP flaws and October 31 for Fragnesia.

What is still unknown

• How many devices were compromised. Palo Alto gives a share of its installed base with exposed management interfaces and says it contacted those customers. It does not say how many were rooted.
• Which builds carry a vulnerable kernel. Palo Alto has published no kernel advisory. Dream says only one of its 11 version profiles, for the 12.x branches, was calibrated end to end, while the advisory covers 10.2 to 12.2.
• What the attacker got. Dream says the persistent tunnel is “likely still active” and that 22 firewalls remain parked. Whether the password spray, backdoor accounts or SAML key attempt worked is unknown.
• Who it is. No actor is named in the documents we could read, and the role of AI tools in writing the exploit is unproven.

Sources and method

We read Palo Alto’s advisory (the HTML page and its JSON record), four Internet Archive captures of it (October 23 at 04:02 and 16:40, October 27 at 17:10 and October 29 at 07:45 UTC; a fifth, from October 22, was rate-limited), Unit 42’s threat brief and its update log, Dream’s report and its October 28 capture, CISA’s KEV feed (catalog version 2026.10.29, released 19:09 UTC) and its October 28 alert, the NVD and CVE.org records for CVE-2026-46300, Red Hat’s CVE data, the May 13 oss-security message, GitHub’s API for the fix commits, our own October 21 report, and BleepingComputer’s article. The count of 20 fixed builds, the 25 Threat IDs, the percentages and the gaps between times are our arithmetic from those pages. The checks were made between 19:10 and 19:40 UTC on October 29. We did not read or run the public Fragnesia exploit, we have not tested anything against a firewall, and Dream’s figures come from artifacts we cannot inspect.