When the Firewall Is the Vulnerability
CVE-2026-0300 gives an unauthenticated attacker root-level code execution on PAN-OS firewalls — no credentials, no interaction required. Here's how the Captive Portal became the entry point, what the attackers did next, and why owning the perimeter is a different category of problem.
A firewall's job is to sit at the boundary between trusted and untrusted networks and decide what passes. CVE-2026-0300, disclosed by Palo Alto Networks on May 6, inverts that arrangement. An attacker on the untrusted side can send specially crafted packets to an exposed PAN-OS service and execute arbitrary code on the firewall itself—no credentials required, no user interaction needed, root privileges from the first instruction.
The vulnerability is under active exploitation. CISA added it to the Known Exploited Vulnerabilities catalog the same day it was disclosed. No patch exists yet.
What the Captive Portal Actually Does
PAN-OS includes a feature called the User-ID Authentication Portal—commonly called the Captive Portal. Its purpose is to resolve a specific problem in enterprise networks: when a user's device connects, the firewall needs to know who is using that IP address in order to apply identity-based policies. For devices that authenticate automatically—domain-joined machines running a User-ID agent—this happens silently. For devices that don't, the firewall intercepts the traffic and redirects the browser to a login page. The user authenticates, the firewall maps their IP to their identity, and policy enforcement proceeds.
This is a non-default feature. To work, it has to accept incoming HTTP or HTTPS connections from devices that haven't yet identified themselves—which means it faces untrusted traffic by design. That exposure is the feature's entire purpose. It is also the attack surface.
The Mechanics of the Flaw
CVE-2026-0300 is a buffer overflow in the Captive Portal service—specifically classified as CWE-787, an out-of-bounds write. To understand what that means: when software receives data, it allocates a fixed region of memory to hold it. A buffer overflow occurs when the incoming data exceeds that allocation and the program fails to stop writing at the boundary. The excess bytes land in adjacent memory regions, overwriting whatever was there.
In PAN-OS, the Captive Portal service fails to validate the length of data in incoming packets before writing it to a buffer. An attacker who sends a packet constructed to overflow that buffer can overwrite memory in a way that redirects the program's execution—causing it to run attacker-supplied code instead of its own. Because the service runs with root privileges, so does that code.
The result: unauthenticated remote code execution on the firewall, with the highest level of system access, triggered by network packets alone.
Why Owning the Firewall Is Different
Most breaches involve compromising something behind the perimeter—an application, a workstation, a misconfigured cloud bucket. A compromised firewall is a different category of problem.
The firewall sees all traffic crossing the boundary. It terminates VPN sessions, meaning it holds or can intercept credentials. It enforces segmentation, meaning an attacker who controls it controls what can reach what. It trusts the internal network implicitly, meaning lateral movement becomes substantially easier once an internal foothold is established from the firewall itself.
Unit 42's tracking of the observed exploitation—designated CL-STA-1132—confirms exactly this progression. After achieving code execution, the attacker injected shellcode into an nginx worker process, immediately deleted crash logs and core dumps to erase the evidence of compromise, then used the firewall's own service account credentials to enumerate Active Directory, targeting domain root and DNS zones. The firewall's privileged position inside the network gave the attacker a ready-made foothold.
The tooling used was deliberately unremarkable: EarthWorm, an open-source SOCKS5 tunneling tool, and ReverseSocks5, an open-source proxy utility that establishes outbound connections from the compromised host to an attacker-controlled controller. Both are publicly available and used by legitimate administrators, which makes signature-based detection harder. The attackers also operated in intermittent sessions over a multi-week period rather than working continuously—a pattern designed to stay below the behavioral thresholds of automated alerting systems.
One additional detail from Unit 42's timeline: the attackers first attempted exploitation on April 9, failed, and succeeded a week later. They then waited four days before deploying tools. On April 29, they triggered a SAML flood against the first compromised device, which caused a second device to become active and inherit the same internet-facing traffic—then exploited that second device using the same vulnerability.
State-Sponsored Attribution
Unit 42 describes CL-STA-1132 as likely state-sponsored based on the operational discipline involved: multi-stage exploitation over weeks, systematic log destruction, minimal footprint tooling, and a focus on identity infrastructure rather than destructive impact. This is consistent with espionage objectives—maintaining persistent, covert access to monitor traffic and harvest credentials rather than announcing presence.
EarthWorm has previously appeared in operations attributed to Volt Typhoon, APT41, and other clusters with state-nexus assessments. That pattern of tooling reuse across groups makes attribution uncertain, and Unit 42 is appropriately cautious with the "likely" qualifier.
Exposure and Patch Timeline
Shodan identifies approximately 225,000 internet-facing PAN-OS instances. The vulnerability applies only to devices where the User-ID Authentication Portal is enabled—a non-default feature, but common in environments with mixed device populations (contractors, BYOD, guest networks). Exploitation risk is highest when the portal is reachable from untrusted networks or the public internet.
Prisma Access, Cloud NGFW, and Panorama are not affected.
No patch exists as of publication. Fixes begin rolling out May 13 for some versions—two days from now—with additional releases through May 28. For the duration of that window, and for every affected version still awaiting a later release date, mitigation is the only available defense: restrict Captive Portal access to trusted internal zones only, and disable Response Pages on any L3 interface where untrusted traffic can ingress. If the portal is not in use, disable it entirely under Device > User Identification > Authentication Portal Settings.
The vulnerability receives a CVSSv4 score of 9.3. Palo Alto Networks has confirmed that exploitation is automatable.
What This Means
Edge devices—firewalls, VPN concentrators, routers—have become a primary target for state-linked actors over the past several years. They hold privileged positions in network architecture, they often run proprietary operating systems with limited endpoint security tooling, and they are trusted by the networks they protect. Compromising one yields substantially more access than compromising an equivalent endpoint.
CVE-2026-0300 follows a pattern that has repeated across Ivanti, Fortinet, Citrix, and Cisco products over recent years: a critical flaw in a service that must accept untrusted input, exploited before patches are available, by actors who understand exactly what that access is worth. The Captive Portal was not negligently exposed—it was operating as designed. The flaw was in the code that processed what it received.
Organizations with PA-Series or VM-Series firewalls running the Captive Portal should assume exposure until the mitigation is applied or the patch is installed.