top of page

CVE-2026-0300: Palo Alto's Captive Portal Has Been Bleeding Root Since April 9. CISA Deadline May 9. Patch Arrives May 13. Hunt Inside.

  • Writer: Patrick Duggan
    Patrick Duggan
  • 1 day ago
  • 6 min read

May 7, 2026 · DugganUSA LLC


Palo Alto Networks disclosed CVE-2026-0300 yesterday — an unauthenticated, root-level remote code execution in the User-ID Authentication Portal (the Captive Portal) on PA-Series and VM-Series firewalls. CVSS 9.3 if the portal is reachable from the internet, 8.7 if restricted to internal trusted networks. Cloud NGFW and Panorama are not affected.


The vulnerability is a buffer overflow in the captive-portal service. An attacker sends a specially crafted packet, the firewall executes shellcode in the nginx worker process at root, and from there the post-exploit playbook runs Active Directory enumeration and drops EarthWorm and ReverseSocks5 — both standard espionage-tier tunneling tools.


Three numbers tell the operational story:


April 9, 2026. The earliest observed exploitation attempt in the wild, per Palo Alto's own advisory and the Wiz / Help Net Security write-ups. By the time the CVE was published yesterday, the active-exploitation window had already been open for nearly four weeks. Anyone running an internet-exposed User-ID Authentication Portal on a PA-Series or VM-Series firewall in the past month is in the hunt-back cohort, not the prevention cohort.


May 9, 2026. CISA added CVE-2026-0300 to the Known Exploited Vulnerabilities catalog yesterday and set the federal civilian executive branch remediation deadline at May 9. That is three days from this post going up. FCEB agencies running affected configurations are racing a deadline that arrives before the vendor patch.


May 13, 2026. The earliest date Palo Alto Networks expects the actual fixed firmware to be available. There is a four-day gap between the federal deadline (May 9) and the vendor patch (May 13). For four days, federally-mandated remediation can only happen via configuration mitigation, not patch application. That gap is the operational story.



What's Actually Vulnerable


Affected: PA-Series hardware firewalls and VM-Series virtual firewalls running PAN-OS configurations that have the User-ID Authentication Portal (Captive Portal) enabled. Per Palo Alto's advisory, the CVSS drops from 9.3 to 8.7 if access to the portal is restricted to trusted internal IP addresses only — meaning if your firewall serves the captive portal to internet-facing zones, you are at the high end of the severity scale.


Not affected: Cloud NGFW deployments. Panorama management appliances. Firewalls without the User-ID Authentication Portal feature enabled.


The captive portal's job is to authenticate users coming through the firewall (typically guest WiFi, BYOD, RADIUS-side flows). It runs as nginx workers on the firewall itself. The buffer overflow allows an unauthenticated attacker to inject shellcode that executes inside one of those worker processes — and nginx workers on PAN-OS run as root.


From there, the espionage playbook: AD enumeration to map the network, then EarthWorm (a Chinese-origin SOCKS5 tunneling tool with a long history in APT campaigns) and ReverseSocks5 (a smaller reverse-proxy backdoor). Both establish persistent C2 channels through the firewall itself, using the firewall's own privilege to bypass other controls.



The Mitigation Tonight (Before the Patch)


If you cannot wait until May 13:


Step one: Determine whether your User-ID Authentication Portal is reachable from untrusted networks. From the PAN-OS GUI, navigate to Network → Network Profiles → Interface Mgmt and inspect which interfaces have the Authentication Portal service enabled. Cross-reference with your security policy to see whether those interfaces are reachable from internet-facing zones. If yes, you are in the worst-case-9.3 configuration.


Step two: Restrict the portal to trusted internal IP addresses only. PAN-OS allows you to configure a permitted-IP list on the Interface Mgmt profile that controls captive-portal exposure. Drop your trusted-IP list to the smallest viable set — internal RFC1918 ranges only, ideally only the user-subnets that legitimately need captive-portal authentication. This drops exposure from internet-facing to internal-only and reduces the CVSS from 9.3 to 8.7. It is a meaningful reduction but not a fix.


Step three: If you do not need the User-ID Authentication Portal at all, disable it. Many networks ran captive-portal authentication years ago for guest WiFi onboarding flows that have since been replaced by 802.1X or cloud SSO. Check whether the portal is still serving any users in the past 30 days. If not, disable the feature on the affected interface profiles entirely. This eliminates the attack surface without waiting for May 13.


Step four: Threat-hunt back to April 9. The active-exploitation window opened a month ago. Even if you patch on May 13, you may already be compromised. Pull the firewall logs for the past 30 days and look for the post-exploit signatures below.



The Hunt


Detection lives in three places: on the firewall itself, in the network egress traffic from the firewall, and in your AD/identity-system logs.



On the firewall


Anomalous nginx worker behavior is the firewall-side signal. Pull the system-level logs (or, if you have console access, the running process tree) and look for nginx workers that are spawning child processes — a normal nginx worker should not be fork/exec-ing arbitrary binaries. From the management interface, the relevant CLI commands are: show system processes for the running tree, show system logs filtered to authd/authentication-portal services for unusual error patterns around the captive-portal service.


The post-exploit AD enumeration phase generates LDAP queries from the firewall to your domain controllers. That traffic is logged on the DC side. Pull DC LDAP logs for the past 30 days and look for connections originating from your firewall's management or service interfaces during hours when no legitimate scheduled job should be running. Successful exploitation pre-positions the attacker to enumerate users, groups, and service principals; that traffic looks legitimate at the protocol level but is anomalous at the timing and source level.



On the network egress


EarthWorm and ReverseSocks5 both establish outbound connections from the firewall to attacker-controlled C2 infrastructure. EarthWorm typically uses port 443 with a custom SOCKS5 framing inside TLS; ReverseSocks5 uses configurable ports but commonly defaults to high non-privileged ports. Pull your firewall's egress traffic from the past 30 days and look for outbound TLS connections originating from the firewall itself (not from internal hosts traversing the firewall) to unusual destinations. A firewall talking outbound to anything other than your management plane, your update servers, and your telemetry collectors is anomalous by definition.


In Microsoft Sentinel terms, against the relevant firewall log table:


PaloAltoSyslog | where TimeGenerated > ago(30d) | where SourceIP == "<firewall-mgmt-ip>" | where Destination !in (known_management_destinations, known_update_servers, known_telemetry_endpoints) | project TimeGenerated, SourceIP, DestinationIP, DestinationPort, BytesSent, BytesReceived | order by TimeGenerated asc


Adapt the table name and column names to your log-shipper schema.



On the identity layer


ReverseSocks5 enables the attacker to pivot through the firewall into the internal network as if they were on it. That pivot typically manifests as authentication events from the firewall's IP into AD, into RDP gateways, into VPN concentrators. Pull AD authentication logs for any successful authentication event where the source IP is the firewall's own management or service IP. There is no legitimate reason for a firewall to authenticate as a user against AD.


In Defender for Identity / AAD sign-in log terms: any sign-in event where the IPAddress field matches the firewall's own internal IP, in the last 30 days, is a high-confidence compromise indicator.



The IOCs in Our Feed


We pulled the public PoC repos via the exploit-harvester. As of this morning the indexed repos include mr-r3b00t/CVE-2026-0300, 0xBlackash/CVE-2026-0300, and bannned-bit/CVE-2026-0300-PANOS. Path indicators captured by the harvester include /opt/pan-honeypot, /var/lib/pan-honeypot, and /var/log/pan-honeypot — those are the canonical install paths used by the public honeypot fixture, useful as a forensics tell if you find them on a real PAN-OS box (they should not be present on a production firewall).


The IOC set is queryable via the public STIX feed at analytics.dugganusa.com/api/v1/stix-feed under indicator type. Free public tier is 25 queries/day; that is enough to pull the CVE-2026-0300 set without paying us.



Summary For The Person Reading This At 11pm


Three actions tonight, in order:


  1. Check whether your User-ID Authentication Portal is exposed to untrusted networks. If yes, restrict to internal IPs only as the immediate mitigation. If you don't need it at all, disable it.

  1. Hunt back 30 days for nginx worker anomalies, firewall-originated AD authentication events, and unusual outbound TLS from the firewall itself. The exploitation window started April 9; if you were exposed and unmitigated, you are in the assume-breach cohort.

  1. Plan to patch on May 13. PAN-OS firmware updates require a maintenance window because they reboot the firewall. Schedule the window now so you are not racing the May 13 release date with an unbooked change-control process.

If you find anything in your hunt and want a cross-check, we are at [email protected].



Receipts


  • Palo Alto Networks security advisory CVE-2026-0300 (May 6, 2026): security.paloaltonetworks.com

  • CISA KEV catalog entry (May 6, 2026): cisa.gov/known-exploited-vulnerabilities-catalog

  • Federal civilian remediation deadline: May 9, 2026

  • Earliest observed exploitation in the wild: April 9, 2026 (per Palo Alto + Wiz)

  • Patch availability: May 13, 2026 (vendor schedule)

  • Help Net Security writeup: helpnetsecurity.com/2026/05/06/palo-alto-firewalls-vulnerability-exploited-cve-2026-0300

  • BleepingComputer: bleepingcomputer.com/news/security/palo-alto-networks-warns-of-actively-exploited-firewall-zero-day

  • Wiz technical analysis: wiz.io/blog/critical-vulnerability-in-pan-os-exploited-in-the-wild-cve-2026-0300

  • Public PoC harvested by our exploit-harvester: github.com/mr-r3b00t/CVE-2026-0300, github.com/0xBlackash/CVE-2026-0300, github.com/bannned-bit/CVE-2026-0300-PANOS

  • Our STIX feed: analytics.dugganusa.com/api/v1/stix-feed

— Patrick Duggan DugganUSA LLC, Minneapolis


Aye.




How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.


bottom of page