CRITICAL: Palo Alto PAN-OS Zero-Day Hands Attackers Root on Internet-Facing Firewalls (CVE-2026-0300)

If you run a Palo Alto firewall with the User-ID Authentication Portal facing the internet, stop reading this and go check your access controls. Then come back. Palo Alto Networks confirmed on May 5 that CVE-2026-0300, a buffer overflow in the User-ID Authentication Portal service of PAN-OS, is being actively exploited in the wild. The flaw lets an unauthenticated attacker send specially crafted packets and walk away with root code execution on PA-Series and VM-Series firewalls. No credentials, no user interaction, no warning shot, just a network packet and a takeover.

The numbers tell the story. Palo Alto rates this at CVSS 9.3 if the portal is accessible from the internet or any untrusted network, and 8.7 if access is restricted to trusted internal IP space. That difference between 9.3 and 8.7 is the difference between a perimeter-shaped hole and an insider-only headache. Either way, it is the kind of bug that will keep a SOC team busy for the next two weeks.

The vulnerability lives inside the Captive Portal feature, which most defenders know as the splash page that prompts users to authenticate before reaching the network behind the firewall. That portal speaks HTTP and HTTPS by design, which means once it is internet-exposed it is reachable by anyone with a curl command and bad intentions. The buffer overflow sits in the packet handling for that service, and according to the advisory, an attacker simply sends a crafted request to trigger arbitrary code execution as root. There is no authentication step to fail, no privilege boundary to cross, no user to phish. That is about as bad as a network-edge bug gets, and it is exactly the class of issue that tends to migrate from limited targeted use to mass scanning faster than vendors can publish IOCs.

The affected versions span every supported PAN-OS branch. PAN-OS 12.1 prior to 12.1.4-h5 and prior to 12.1.7, every 11.2 build before 11.2.4-h17, 11.2.7-h13, 11.2.10-h6, and 11.2.12, the entire 11.1 branch up through several specific hotfix targets, and a handful of 10.2 ranges all carry the flaw. Customers running Prisma Access, Cloud NGFW, or Panorama appliances catch a break here because those products are not impacted. Anyone still on a PA-Series or VM-Series box with User-ID Authentication Portal enabled is in scope. The vendor has been specific that it is the portal feature, not PAN-OS itself, that determines exposure, so a firewall without User-ID Authentication Portal turned on is not vulnerable to this particular issue. That nuance matters when you are triaging hundreds of devices in a large estate and need to figure out which ones to fix first.

Patches are rolling in waves. Palo Alto plans to start releasing fixes on May 13 and continue through May 28, with different code branches landing on different days. That timeline matters because the vendor disclosed the issue while exploitation was already underway, which is unusual. The advisory describes the activity as limited exploitation targeting portals exposed to untrusted IP addresses or the public internet. Translation: someone, somewhere, is already burning this on real targets, and the rest of the threat actor ecosystem now knows about it. Anyone who has been watching edge-device exploitation over the past two years can probably guess what comes next. The window between disclosure and broad opportunistic scanning tends to be measured in hours, not days.

Mitigations exist for organizations that cannot patch immediately, and they should be applied right now regardless of patch readiness. The first option is restricting User-ID Authentication Portal access to trusted zones only, which means putting an ACL or zone policy in front of the portal so that only known internal subnets can reach it. The second is disabling the Authentication Portal entirely if the feature is not actively used, which is found under Device, User Identification, Authentication Portal Settings in the management interface. Either change neutralizes the public attack path until the patched build for your branch is available. Anyone who wants to be thorough can do both, since this is a vulnerability where defense in depth costs almost nothing and buys real risk reduction.

Detection is harder than mitigation but not impossible. The exploit is delivered as crafted HTTP or HTTPS traffic to the captive portal endpoint, so packet captures, NetFlow telemetry, or web application firewall logs from any device sitting in front of the firewall management plane can be reviewed for unusual request patterns hitting the portal URI. Anomalous user agents, malformed Content-Length headers, or large request bodies aimed at authentication endpoints are all worth flagging. Beyond that, hunt for unexpected processes, new outbound connections, or configuration changes on the firewall itself. A compromised PAN-OS box can be used to pivot deeper, exfiltrate VPN credentials, or modify firewall rules to permit follow-on activity, so the post-exploitation footprint may show up downstream rather than on the device itself. Anyone with EDR coverage on internal hosts that the firewall protects should look for sudden lateral movement originating from the firewall's IP, since that is one of the cleanest signals that an edge device has been turned against its owner.

There is precedent worth remembering here. CVE-2024-3400, the GlobalProtect command injection from two years ago, set the standard for how quickly attackers move on PAN-OS edge bugs. State-aligned actors and ransomware crews both adopted that vulnerability inside a week. CVE-2026-0300 has the same shape, an unauthenticated network-facing root code execution against a widely deployed perimeter device, and the same expected trajectory. CISA has not yet added it to the Known Exploited Vulnerabilities catalog as of this writing, but federal agencies running PAN-OS should expect that to change shortly, with the typical two to three week patch deadline that follows. Private sector defenders should not wait for that nudge. The threat actors will not.

It is also worth understanding why edge devices keep ending up in headlines like this one. Firewalls, VPN concentrators, and authentication portals sit in a privileged position on the network. They terminate traffic from untrusted sources, often run as root, and frequently have direct routes into management networks and identity systems. A bug in that code path is not just a vulnerability in a single appliance, it is a vulnerability in the trust boundary itself. That is why nation-state operators have shifted so much of their attention from endpoint malware to edge exploitation over the past three years. The compromise is quieter, the access is more durable, and the detection coverage is usually thinner. Every organization running internet-facing security infrastructure should treat each of these CVEs as a reminder that the perimeter is not an artifact of legacy architecture, it is still a live attack surface that requires the same vulnerability management rigor as any production server.

The MSP angle is the obvious one. Edge device patching is one of the highest-leverage services a managed provider can offer right now, because every firewall, VPN concentrator, and remote access gateway in the field is one CVE away from full network compromise. Clients who have been resisting an upgrade cycle on their Palo Alto gear because it still works are exactly the ones sitting on vulnerable 10.2 builds. This is also a clean opportunity to pitch external attack surface monitoring, because the only reason an attacker can hit the User-ID Authentication Portal is that someone, somewhere, exposed it to the internet without realizing it. Finding those exposures before the bad guys do is a service worth paying for, and it is a lot easier to sell on a Tuesday morning when the news is full of stories about Palo Alto firewalls falling over.

For everyone else, the playbook is simple. Inventory every PA-Series and VM-Series firewall in the environment. Confirm whether User-ID Authentication Portal is enabled. If it is, lock it down to trusted zones today and patch the moment the relevant fixed build for your branch lands. If it is not, document that fact so you do not panic the next time someone asks. And keep an eye on the advisory page for IOCs, because vendors often update those after initial publication once incident response data comes in. This is a critical edge bug being exploited right now, and the only acceptable timeline is before someone runs a Shodan query.