PAN-OS Management RCE: PHP2Shell Chain Reaches Root and AD

Palo Alto Networks confirmed on 28 October 2026 that attackers are exploiting PHP2Shell, two unauthenticated PHP flaws, against internet-exposed PAN-OS management interfaces. Chained with the Fragnesia Linux kernel bug, this PAN-OS management RCE ends with root on the firewall. In one campaign reported separately by Israeli firm Dream, the attackers then went after Active Directory credentials.

What did Palo Alto actually confirm on 28 October?

Palo Alto confirmed exploitation in the wild. Its advisory update on Wednesday, 28 October 2026, says: “Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet.” That is the only vendor-confirmed part of this story, and it is enough to act on.

The bugs are CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. Both score CVSS 9.2 and both allow unauthenticated remote code execution on systems running affected PHP versions. The attacker needs no login and no stolen session, only reachability. Palo Alto says “no special configuration is required to be affected by this issue.”

The PHP Foundation shipped upstream fixes on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. One week later, exploitation of a downstream appliance was confirmed. Those releases do nothing for your firewall: the appliance fix is the PAN-OS hotfix in Palo Alto’s version matrix. Closing a ticket because “PHP is patched” fixes the wrong asset.

Keep the vendor’s statement separate from the wider campaign. Dream reported a suspected China-nexus actor rooting 25 servers in the United States, Japan, Taiwan and South Korea, three of them in a U.S. government-affiliated environment. Dream described the victims only as running “specific versions of a large vendor’s firewall software” and did not name the vendor.

The Hacker News suggested the victims may be Palo Alto customers, citing the advisory’s timing and the absence of exploitation reports from other network security vendors, and framed that explicitly as inference. The China-nexus attribution is Dream’s alone. Palo Alto’s advisory names no actor, gives no victim count and does not mention Active Directory.

For the executive briefing, three lines: the vendor confirms attacks on exposed management interfaces; a research firm describes a wider campaign that may be the same activity or a separate one; and some fixed builds are not out yet.

Where does PAN-OS management RCE land: MGT, XML API or dataplane?

The vulnerable code sits in the management web interface. Palo Alto’s wording: “This issue strictly affects the management web interface, which includes the HTTPS web UI and XML API service. It affects the dataplane interface only if a management profile is attached to it.”

So the question for each device is not whether the firewall faces the internet (that is its job) but whether an untrusted address can reach a management service on it. Check three paths:

• The dedicated MGT port. Traffic to the MGT interface is not governed by dataplane security policy. Access is controlled in the management interface settings, mainly Permitted IP Addresses, so a tight rule base does not protect it. A routable MGT address with an empty permitted list answers anyone.
• Interface management profiles on dataplane ports. A profile that enables HTTPS on an untrust interface puts that interface in scope. These profiles get added for a remote support session or a migration weekend and then stay for years.
• The XML API. Teams that hide the web UI often forget that automation reaches the same service. If a cloud tool, MSP platform or SOAR integration calls the API from outside, that path is attack surface and needs the same restriction.

Panorama sits under the same guidance. Palo Alto says the risk “on PAN-OS and Panorama is minimized by restricting access to the management interface to only trusted internal IP addresses.” Treat every Panorama instance exactly like a firewall.

Some customers had protection before the news broke. Those with Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 and later received coverage through Threat ID 543004, released at 22:21 PT on 20 October 2026, a day before the PHP fixes went public.

That coverage is narrow. It needs that subscription, that branch, and an inspection path that actually sees management traffic. Palo Alto’s advance-coverage statement does not extend to older branches.

How does a web bug become root and then a domain problem?

PHP2Shell gives the attacker code execution as the web service. Fragnesia turns that into root. Fragnesia is CVE-2026-46300, a Linux kernel local privilege escalation rated CVSS 7.8, in the operating system underneath the appliance.

CISA added CVE-2026-46300 to its Known Exploited Vulnerabilities (KEV) catalog and explained why in its own words: “This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP web shells and run commands as root.” The federal remediation deadline is 31 October 2026.

The 7.8 is the trap. CVSS scores one bug in isolation, and a local privilege escalation looks moderately urgent on a spreadsheet because it needs a foothold first. Here the foothold is free and unauthenticated. A team that patches the two 9.2 CVEs and parks the kernel bug for next month’s cycle leaves the root step in place.

KEV deadlines legally bind only U.S. federal civilian executive branch agencies under Binding Operational Directive 22-01. For everyone else, catalog inclusion is still evidence of real exploitation, a stronger signal than any base score.

Root on a firewall is rarely the goal. Describing the campaign it tracked, Dream wrote: “The attacker then launched attacks against Active Directory. The recovered artifacts confirm credential extraction and directory enumeration.”

Firewalls are wired into identity. A typical PAN-OS deployment talks to the directory for admin authentication, group mapping and user identification, and often holds service-account credentials to do it. It also has network paths to domain controllers that most DMZ hosts never get.

From root, an attacker can read the configuration, collect those secrets and query the directory from a host the SOC files under infrastructure rather than suspects. At that point the incident is about identity, not a perimeter device.

Which PAN-OS maintenance lines still lack a shippable fix?

PAN-OS 12.2 is fixed at 12.2.4-h1 and later. Several lines in 12.1, 11.2, 11.1 and 10.2 had fixes listed only as ETAs for 29 or 30 October when the advisory was updated. Each value below is the first fixed hotfix for that maintenance line: anything lower is affected.

Branch	Affected if running (fixed at the listed hotfix or later; ETA where given)
12.2	< 12.2.4-h1
12.1	< 12.1.4-h13 (ETA 29 Oct), < 12.1.7-h11, < 12.1.10-h3 (ETA 30 Oct)
11.2	< 11.2.4-h23 (ETA 30 Oct), < 11.2.7-h23, < 11.2.10-h16, < 11.2.13-h4, < 11.2.16-h1
11.1	< 11.1.4-h38, < 11.1.6-h40, < 11.1.7-h12 (ETA 30 Oct), < 11.1.10-h36, < 11.1.13-h16, < 11.1.16-h4
10.2	< 10.2.7-h39 (ETA 30 Oct), < 10.2.10-h42 (ETA 29 Oct), < 10.2.13-h27, < 10.2.16-h12, < 10.2.18-h13

Read the matrix by maintenance line, not by branch. “We’re on 11.1” tells you nothing. Run show system info on every firewall and Panorama instance and compare the exact release and hotfix against the table. Fleets drift: the HA pair gets upgraded, the DR unit in another region does not.

If your line’s hotfix is already out, treat it as an emergency change and schedule it now. If it shows an ETA, apply the compensating controls below today, then patch the day the build ships. Federal agencies on ETA lines have the tightest window, with the 31 October KEV deadline for Fragnesia landing one or two days after those builds are due.

What can you do before the hotfix lands?

Restrict management access to trusted internal IP addresses, today, on every PAN-OS and Panorama device. That one change puts an unauthenticated bug out of reach of outside attackers. It is also Palo Alto’s long-standing deployment guidance, restated in this advisory.

For versions without a fix, Palo Alto lists interim mitigations:

• Route incoming MGT traffic through a dataplane port, for example by enabling a management profile on a DP interface.
• Replace the certificate for inbound management traffic.
• Decrypt inbound traffic to the management interface so the firewall can inspect it.
• Enable threat prevention on inbound traffic to management services.

The logic: traffic on the dedicated MGT port does not pass through the inspection engine, so the workaround moves management onto a dataplane port, decrypts it and lets threat prevention signatures see the requests.

It works, but it adds moving parts to the one path you use to repair the firewall. Test it on a non-critical device first and keep an out-of-band way in.

Treat virtual patching as exposure reduction, not remediation. Confirm the subscription is active, the content version includes the relevant threat ID, and the security profile is attached to the rule carrying management traffic. A signature that never sees the traffic protects nothing. And none of it helps if an attacker got in before 20 October, which raises the harder question.

If management was on the internet, what is the assumed-breach check?

If any management service was reachable from the internet in this window, assume compromise until evidence says otherwise. Exploitation was confirmed after the fact, the start date is unknown, and a rooted appliance can lie about its own state. Work in this order:

1. Preserve before you patch. Upgrading or rebooting can destroy evidence. Export relevant logs and a Tech Support File, and record the running version, administrator list, interface configuration and recent configuration changes.
2. Check the appliance. Look for unexpected management-plane processes, new local or admin accounts, commits that match no change ticket, and unfamiliar files in web-served paths, since CISA names PHP web shells as the implant. Take indicators from Palo Alto’s advisory, not secondhand lists.
3. Hunt in identity telemetry. Dream’s artifacts showed credential extraction and directory enumeration. Look for authentication from the firewall’s addresses or service accounts outside their normal pattern, unusual LDAP query volume, and those accounts appearing on hosts they never touch.
4. Rotate after containment. Patching does not evict anyone. Rotate firewall administrator credentials, API keys, and every service-account or domain credential the device stored or could reach.

For scale, Dream’s 25 rooted servers are an observed victim count, not an estimate of every exposed device or of the campaign’s full reach.

Still unknown: when exploitation began, whether Palo Alto’s observed attacks and Dream’s campaign are the same operation, how many PAN-OS management interfaces answer from the internet, and whether rooted devices keep persistence that survives a hotfix. Plan for the worst-case reading on your own devices and the cautious one in public statements.

If the identity hunt finds anything, the scope has moved past the firewall. An assumed breach assessment that starts from the firewall’s foothold measures what an attacker could reach from there, and an Active Directory penetration test shows which paths those harvested service accounts open.

Why does an exposed management plane keep paying attackers?

It is a large web application running with near-root privilege on the most trusted device in the network, and every bug anywhere in its stack inherits that privilege. This time the entry point is PHP and the escalation is the kernel. Last time it was PAN-OS code itself.

The record is consistent. In November 2024, attackers chained CVE-2024-0012, an authentication bypass in the PAN-OS management web interface, with CVE-2024-9474, a privilege escalation, to take over exposed firewalls. In April 2024, CVE-2024-3400, a CVSS 10.0 command injection in GlobalProtect, was exploited before a fix existed. Different components, same outcome: the perimeter appliance ended up working for the attacker.

Exposure usually comes from drift, not design. Nobody decides to publish the admin panel. A management profile goes on the outside interface for a vendor call. A cloud firewall’s security group gets opened for an MSP. A lab unit with a public address joins the production Panorama. The inventory says management is internal; the internet says otherwise.

From our engagements: during external tests, the exposed management plane we find is almost never the primary firewall the network team watches. It is the HA peer, the DR site, the forgotten branch unit, the XML API left open for a monitoring tool, or a Panorama instance in a cloud VPC.

That is what an external network penetration test is for: enumerate every public address and cloud asset, fingerprint management services including APIs, and prove which ones answer. Pair it with a firewall and management-plane configuration review that walks Permitted IP Addresses, every interface management profile and every HA and DR peer, so the next PAN-OS management bug finds nothing to land on.

FAQ

Are CVE-2026-109618 and CVE-2026-109619 the same bug?

No. They are two separate PHP vulnerabilities, each rated CVSS 9.2, that are exploited together under the name PHP2Shell to achieve unauthenticated remote code execution.

Does updating PHP fix my Palo Alto firewall?

No. The upstream PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 releases do not patch the appliance. Apply the PAN-OS hotfix Palo Alto lists for your exact maintenance line.

Is Panorama in scope of the management-access guidance?

Yes. Palo Alto says the risk on both PAN-OS and Panorama is minimized by restricting management interface access to trusted internal IP addresses.

Does Threat ID 543004 cover every PAN-OS branch?

No. Palo Alto says the advance coverage applied to customers with Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 and later. Older branches rely on the interim mitigations and the hotfixes.

What is the federal deadline for CVE-2026-46300?

CISA set 31 October 2026 for U.S. federal civilian agencies after adding Fragnesia to the KEV catalog. Other organizations are not legally bound, but KEV inclusion is evidence of active exploitation and should drive priority.

Should an exposed management interface be treated as a domain compromise?

Treat it as a possible one. If management was reachable from the internet, preserve evidence, hunt for Active Directory credential extraction and enumeration from the firewall's accounts, and rotate stored credentials after containment.

Want to know which of your management planes answer from the internet before someone else checks? agent::offense runs external network penetration tests that find exposed management services across HA, DR and cloud estates, and assumed breach assessments that follow a firewall foothold into identity.