PAN-OS CVE-2026-0300 Captive Portal RCE: The Pre-Patch SMB Playbook

On May 6, Palo Alto Networks published an advisory for CVE-2026-0300, a CVSSv4 9.3 buffer overflow in the User-ID Authentication Portal (the marketing name is Captive Portal) that gives an unauthenticated attacker arbitrary code execution as root on PA-Series and VM-Series firewalls. The same day, CISA added it to the KEV catalog with a federal remediation deadline of May 9. Unit 42 published a threat brief attributing limited but active exploitation to CL-STA-1132, a likely state-sponsored cluster that injects shellcode into the nginx worker process and uses the foothold to deploy EarthWorm and ReverseSocks5 tunnels into the protected network. Rapid7 reports Shodan shows roughly 225,000 internet-facing PAN-OS instances. The patches do not exist yet. The first wave is scheduled for May 13, with the rest landing by May 28.

That is the situation. If your perimeter firewall is a Palo Alto and the Authentication Portal is enabled and reachable from the internet, you are in the high-risk cohort and you have at minimum three days of pre-patch exposure to manage. This article is the playbook for getting through that window cleanly.

Who is actually affected

The advisory is precise about the exposure conditions. Both of the following must be true for a firewall to be exploitable:

• User-ID Authentication Portal is enabled. You can verify this at Device > User Identification > Authentication Portal Settings by checking whether Enable Authentication Portal is ticked.
• An interface management profile with Response Pages enabled is attached to a Layer 3 interface in a zone where untrusted or internet traffic can ingress. You can verify this at Network > Interface > (interface) > Advanced Tab > Management Profile.

Prisma Access, Cloud NGFW, and Panorama are not affected. PA-Series hardware appliances and VM-Series virtual firewalls are. The vulnerable code is in the nginx-fronted portal that serves the response page for unauthenticated users hitting the firewall. An oversized crafted packet to that portal triggers an out-of-bounds write (CWE-787) that lands shellcode inside an nginx worker. From there the attacker has root.

If you are running PAN-OS 12.1, 11.2, 11.1, or 10.2, every minor version below the patched hotfix train is vulnerable until May 13 or May 28 depending on which train. The version-specific table in the Rapid7 advisory is the cleanest reference.

The five-step pre-patch SMB playbook

Step 1: Determine exposure in under 30 minutes

Most SMBs do not have a CMDB row that says "perimeter firewall is a PA-440 with Captive Portal on." That is fine. The check is fast. Log into each firewall and inspect three settings:

1. Device > User Identification > Authentication Portal Settings. Is Enable Authentication Portal checked?
2. Network > Interface Mgmt Profiles. Which profiles have Response Pages enabled?
3. Network > Interfaces. Are any of those profiles attached to interfaces facing untrusted zones, including the internet-facing zone?

If the answer to all three is yes, you have a pre-patch exposure. If the Authentication Portal is disabled or the response-page profile is only attached to internal interfaces, you are not in the exploit path. Document the answers per firewall. You will need that record for the post-patch validation step.

Step 2: Apply the workaround tonight

Palo Alto offers two workarounds. Pick whichever applies to your environment. Do not wait for the May 13 patch.

Workaround A (preferred, full mitigation): disable the User-ID Authentication Portal entirely if it is not required for your operation. SMBs commonly enabled it years ago for a Wi-Fi guest network or a one-off identity mapping use case and never turned it off. Device > User Identification > Authentication Portal Settings, uncheck Enable Authentication Portal, commit. Done.

Workaround B (when the portal is required): restrict portal access to trusted internal zones only, and disable Response Pages in the Interface Management Profile attached to every L3 interface in any zone where untrusted traffic ingresses. Keep Response Pages enabled only on interfaces in trust or internal zones where legitimate user browsers ingress. Refer to Step 6 of Palo Alto's Live Community article and Knowledgebase article for the exact click path.

If you have a Threat Prevention subscription and you are on PAN-OS 11.1 or later, also enable Threat ID 510019 from Applications and Threats content version 9097-10022. The decoder requires PAN-OS 11.1+ for support, so on older trains the threat ID will not help. Do not treat this as a substitute for the workaround.

Step 3: Hunt for prior exploitation

Unit 42 confirms exploitation has been ongoing for weeks before the public advisory. Their cluster CL-STA-1132 is described as operationally restrained: short access windows, log deletion, tunneling tools (EarthWorm, ReverseSocks5), credential reuse for Active Directory enumeration. That is hard to detect after the fact. The hunt below is the realistic minimum.

Pull the last 30 days of HTTPS traffic logs for the portal-facing interface. The query you want runs against Panorama, your SIEM, or whatever logs the firewall ships:

# PAN-OS CLI: pull traffic logs for the captive portal IP/port the last 30 days
show log traffic direction equal forward query "addr.dst eq <PORTAL_IP> and \
  port.dst eq 6082 and receive_time geq '2026/04/10 00:00:00'"

# Look for the URL filtering and threat logs as well
show log url query "addr.dst eq <PORTAL_IP> and receive_time geq '2026/04/10 00:00:00'"
show log threat query "addr.dst eq <PORTAL_IP> and receive_time geq '2026/04/10 00:00:00'"

What you are hunting for: requests to the portal endpoint with abnormally long URL paths or oversized POST bodies, repeated unauthenticated POSTs from a single IP, user-agents that do not match a normal browser fleet, and any successful access from IPs in countries or ASNs that your user base does not include. Then pull data-plane outbound logs and look for new TLS sessions from the firewall itself to IPs not seen in the last 90 days. CL-STA-1132's tunneling tools beacon outbound. The firewall reaching out to a residential ISP or a hosting provider you do not use is the highest-confidence signal.

If the firewall has been compromised, you cannot trust its own logs. Pull what you can off-box to a write-once SIEM index or cold storage before doing anything else, including any future reboot or upgrade.

Step 4: Patch as the trains land

Palo Alto's patch ETA by train (per the Rapid7 table):

• May 13: 12.1.7, 11.2.7-h13, 11.2.10-h6, 11.1.4-h33, 11.1.6-h32, 11.1.10-h25, 11.1.13-h5, 10.2.10-h36, 10.2.18-h6.
• May 28: 12.1.4-h5, 11.2.4-h17, 11.2.12, 11.1.7-h6, 11.1.15, 10.2.7-h34, 10.2.13-h21, 10.2.16-h7.

The right move is: apply the workaround now, schedule the patch as soon as your specific hotfix is published, validate with a re-check of all three exposure settings post-upgrade, and only then re-enable the portal if you applied Workaround A. Do not skip the validation. Configuration drift between commits is a real cause of "we patched and we are still vulnerable" outcomes.

Step 5: Decide what changes about your firewall posture

This vulnerability is not unique. PAN-OS has had a string of critical advisories over the last two years (CVE-2024-0012, CVE-2024-9474, CVE-2024-3400). The pattern is consistent: edge management surfaces enabled by default or by historical convenience, exposed to the internet, become the breach point. The lesson is not Palo Alto-specific. It applies to every edge appliance that surfaces a portal, a VPN, a management plane, or a SaaS-style helper service.

Three durable changes pay off:

• Edge management surface inventory. For every internet-facing appliance, document every service that listens on a public IP. SSL VPN portals, Captive Portals, GlobalProtect, management interfaces, REST APIs. The list is what attackers see; you should see the same list.
• Default-deny on management surfaces. Whatever does not need to be on the internet should not be on the internet. The Captive Portal is a service for users on a known internal Wi-Fi or a known location. There is no operational reason for it to answer 0.0.0.0/0.
• Pre-patch operational discipline. Edge appliance vendors will continue to ship critical RCE bugs. Your team needs a five-step playbook (this article is one) that runs the same way every time: confirm exposure, apply workaround, hunt, patch, re-validate. Practice it on the small advisories so it works on the big ones.

The CL-STA-1132 footnote

Unit 42's brief calls out one detail that is worth its own note: this cluster uses non-persistent access windows. They get in, do their work, get out, and clean up. They do not maintain a permanent implant on the firewall. That tradecraft is a deliberate adaptation to the fact that edge appliances are now patched and rebooted frequently enough that persistent implants get evicted. Detection has to assume the same thing. By the time you go looking for an implant, there is nothing on disk. The artifacts you have are network telemetry, log gaps, and lateral movement traces inside the protected network. Plan your hunt accordingly.