Palo Alto PAN-OS Zero-Day CVE-2026-0300 Hit by State Hackers

Anyone who has ever been paged at 3am because a perimeter firewall rebooted itself knows where this story is going. CVE-2026-0300 is a CVSS 9.3 unauthenticated remote code execution bug in the PAN-OS Captive Portal, with root privileges, and there is no patch. Palo Alto's own Unit 42 says state-backed operators have been quietly working it since April 9.

The Numbers

Start with the score. CVSS 9.3 is the kind of number that, in production incidents I've seen, instantly trumps every other ticket on the board. As The Register reported, the flaw lives in the User-ID Authentication Portal, a memory corruption bug that hands attackers root with no login required. Both PA-Series appliances and VM-Series virtual firewalls are in scope. That second one matters because plenty of cloud-heavy shops assume their VM-Series instance behind a load balancer is somehow safer than the metal box in the rack. It is not.

The timeline is the part that should make platform leads uncomfortable. First failed exploitation attempts: April 9. Successful RCE on a targeted firewall: roughly a week later, so around April 16. Log and crash report cleanup: immediate. Active Directory probing: shortly after. Forced failover to a secondary firewall via an authentication traffic flood: April 29. Compromise of that secondary device and additional remote access tooling installed: same window. Public disclosure: May 7. CISA listing in the KEV catalog: already done.

That is roughly four weeks of unattributed root access on internet-facing security infrastructure before defenders even had a CVE to grep for. For teams running PAN-OS in front of payment systems, sportsbooks, or trading venues, four weeks is not a window. It is an era. It covers a full month-end close, two payroll runs, and at least one product launch. The cluster is tracked as CL-STA-1132 and described as "likely state-sponsored," which is vendor-speak for "we are confident enough to say it out loud but not confident enough to name a country."

The technical signature: shellcode injected into an nginx worker process running on the device. Unit 42 attributes the campaign. CISA has codified it. Palo Alto's only mitigation guidance is to restrict the User-ID Authentication Portal to trusted networks or disable it entirely. There is no patch as of publication.

What's Actually New

Honestly, not much, and that is the point. Palo Alto firewalls have been a regular target for attackers for the past two years, with multiple zero-day campaigns hitting internet-facing PAN-OS devices before patches were ready. Attackers have chained flaws in previous PAN-OS rounds to pivot deep into networks. So the headline "perimeter device gets popped" is not news. What is new is the operational maturity of CL-STA-1132.

Look at the choreography. Failed attempts on April 9 suggest the attackers were tuning their exploit against live targets, not in a lab. A week later they land RCE and immediately wipe logs and crash reports. That tells you they had a forensic playbook ready to go before the first packet flew. Then they probe Active Directory, which is the standard pivot, but they do it while continuing to scrub traces from the firewall. Parallel operations, not sequential.

The April 29 move is the part I would frame for any CTO who still thinks "we have HA, we're fine." The attackers triggered a flood of authentication traffic specifically to force a failover to the secondary firewall, then compromised that one too and dropped additional remote access tools on it. That is not opportunism. That is an operator who understands PAN-OS HA semantics, knows that the secondary box is often less monitored, and has decided redundancy is a feature for them, not for you.

My take: the genuinely new signal here is that "highly available" perimeter pairs are now a single failure domain from the attacker's perspective. If your incident response runbook assumes the secondary firewall is a clean fallback during an active intrusion, that assumption is dead. Both nodes are in scope, and a clever adversary can flip you to the one they want to compromise next.

What's Priced In for Security Teams

For anyone running PAN-OS, the existence of another unauthenticated RCE in a portal feature is, depressingly, priced in. Teams I've worked with at iGaming operators in Malta and at fintechs running real-money rails have spent the last 18 months building muscle memory around PAN-OS emergency mitigations. The shape of the response: lock down management plane, restrict the portal, audit egress from the firewall itself, hunt for nginx anomalies. None of that is novel.

What should not be priced in, but probably is, is the absence of a patch on disclosure day. CISA's KEV listing without a vendor fix puts CISOs in an awkward seat. Federal agencies have binding deadlines to remediate KEV entries, but the only remediation available right now is to disable a production feature. That is a real operational cost. If your captive portal is how contractors, guest WiFi, or BYOD users authenticate, "disable it entirely" means a help desk surge starting Monday.

The surprise, for me, is the AD-probing detail. Mapping the attacker's actions to MITRE ATT&CK, you get Initial Access via Exploit Public-Facing Application, Defense Evasion via Indicator Removal, and Discovery against Active Directory, all from a foothold on the firewall itself. Most SOCs tune their AD anomaly detection to assume the source is an endpoint or a server. They are not looking for LDAP queries originating from a perimeter appliance's network position. That blind spot is what makes firewall compromises so valuable to state-backed crews.

Contrarian View

The consensus reaction will be "PAN-OS is broken, rip and replace." I think that is wrong, and expensive, and would not actually fix the underlying problem. Every major firewall vendor has shipped unauthenticated RCEs in management or auth-adjacent features over the past two years. Swapping vendor logos buys you a different CVE feed, not a different threat model.

The uncomfortable read: the real failure here is not Palo Alto's code quality, it is the industry-wide habit of exposing rich authentication portals on internet-facing security appliances. Captive portals, SSL VPN landing pages, management interfaces that "should" be locked down but never quite are. Every one of those is a parser written in C-adjacent code, sitting on the dirty side of the network, processing untrusted input. The attack surface is the architecture, not the vendor.

If you are tempted to greenlight a migration off PAN-OS this quarter, ask the harder question first: why is any authentication portal reachable from the public internet at all? Cloudflare-style identity-aware proxies, ZTNA gateways, and segmented admin planes exist precisely to put a layer between the open internet and these fragile parsers. That is the structural fix.

Key Takeaways

• Mitigate today, do not wait for the patch: restrict the User-ID Authentication Portal to trusted networks or disable it. CVE-2026-0300 is being actively exploited and is in the CISA KEV catalog.
• Both HA nodes are compromised territory: CL-STA-1132 forced failover via auth flooding and popped the secondary firewall too. Treat your HA pair as a single trust boundary during IR.
• Hunt the nginx worker: the documented TTP is shellcode injection into nginx on the device. If you have any telemetry off the firewall plane, look for anomalous child processes, outbound connections, and missing crash reports.
• Watch AD queries from firewall network positions: attackers probed Active Directory after the foothold. Tune detections so LDAP and Kerberos traffic from perimeter appliances does not get a free pass.
• Assume four weeks of dwell time on disclosure day: first exploitation attempts started April 9. If your PAN-OS box is internet-facing, your IR scope is "since early April," not "since May 7."