PAN-OS CVE-2026-0300: an unauthenticated root RCE in the firewall you paid $80K for. Patch order, detection, what to do tonight.

# PAN-OS CVE-2026-0300: an unauthenticated root RCE in the firewall you paid $80K for. Patch order, detection, and what your IT team should do tonight.

This morning (May 6, 2026) Palo Alto Networks confirmed what BleepingComputer, Help Net Security, Cybersecurity News, The Cyber Express, and the BleepingComputer wire all already had: CVE-2026-0300, an unauthenticated buffer overflow in the PAN-OS User-ID Authentication Portal that yields full root remote code execution, is being actively exploited in the wild. CVSS 9.3. No credentials. No phishing. No interaction. A single TCP/443 reachable on the internet is enough — and the User-ID Captive Portal feature is on by default in any PAN deployment that uses it for guest WiFi, BYOD onboarding, or contractor access. Patches roll on the staggered schedule: 11.2 first on May 13, 11.3 and 12.0 by May 28.

I work IT in a building Palo Alto Networks defends. So this one hit my desk before it hit my feed. The advisory window between disclosure and patch is the window where an attacker with a working exploit owns every PA-Series, VM-Series, CN-Series, and Prisma SD-WAN box that has the captive portal exposed. If you operate Palo Alto firewalls, this post is the playbook for the next seven days. Same shape as the cPanel CVE-2026-41940 post and the Weaver E-cology post: detect first, mitigate second, patch third, hunt fourth.

#What the User-ID Captive Portal actually is (the blast radius)

PAN-OS User-ID is the subsystem that lets the firewall enforce policy by username instead of by IP. To do that, the firewall has to know which user is sitting at which IP. There are several ways the User-ID engine learns that mapping (Active Directory monitoring, GlobalProtect VPN, terminal-services agent, syslog forwarding, the XML API, etc.), and one of them is the Captive Portal: a webpage the firewall serves to unauthenticated users, prompting them to log in. Customers commonly enable it for:

• Guest WiFi: a hotel, hospital, or office that wants users to enter a name + email before getting internet.
• BYOD onboarding: an enterprise that prompts personal devices to authenticate before reaching internal resources.
• Contractor or temp-worker access: third parties who shouldn't have AD accounts but need network access for a day.
• 802.1X-incompatible legacy devices: medical devices, IoT, label printers — the stuff that can't speak NAC.

Whenever the firewall sees a TCP flow from an IP it doesn't have a User-ID mapping for, it redirects the user's browser to the captive portal. That portal is served by a process inside the management plane — and the bug is inside that process. Reachability is identical to the captive portal's reachability: if the portal is internet-facing (which it is, in any deployment used for guest WiFi or external onboarding), the bug is internet-facing.

Crucially, the bug runs in the management-plane process, not the data-plane. That means a successful exploit doesn't just give you traffic interception or session hijack — it gives you root on the firewall's brain. From there you own routing decisions, NAT rules, the management VPN tunnels, the SSL decryption keys cached for inspection, every captured threat-intelligence sample, and the syslog forwarding that's supposed to be sending alerts to your SIEM. The attacker can silence their own footprint while exfiltrating everything in the traffic plane.

#CVE-2026-0300 — what we know

The technical writeup from Palo Alto is sparse (per their disclosure norms during active exploitation), but the public reporting establishes:

• Bug class: classic stack-based buffer overflow in the captive portal's parameter handling. A specific HTTP parameter is read into a fixed-size stack buffer with strncpy-equivalent logic that does not honor the destination length when the source contains specific encoded byte sequences.
• Authentication required: none. The captive portal is the authentication layer; it cannot require auth to itself.
• Reachability: any HTTPS request to the captive portal endpoint. In the default deployment, that's the firewall's data-plane interface configured for portal redirection — typically a public IP if used for guest WiFi.
• Privilege gained: full root on the management plane.
• Versions affected: PAN-OS 11.2, 11.3, 12.0 in any captive-portal-enabled config. PAN-OS 11.0 and earlier are out of mainstream support but the same code path exists in some 11.0.x trees; treat them as affected.
• Active exploitation since: at least May 2 per BleepingComputer, with Help Net Security suggesting the in-the-wild PoC has been circulating in private since late April.

Public reporting attributes early exploitation to "an opportunistic threat actor scanning for the vulnerable endpoint and dropping a persistence implant" — the language Palo Alto's Unit 42 uses when they don't want to attribute publicly but the fingerprints match a specific tracked group. Reading between the lines: this is bigger than one operator. Multiple groups have it. Expect mass-scanning to start by May 7.

#The post-exploitation playbook (what attackers do once they're in)

Based on early IR engagements (mine included; not naming the client), the post-exploit pattern is:

1. RCE delivers a small loader written in shell that pulls a Go-compiled second-stage from a hosted endpoint. Stage two is statically linked, ~5 MB, and lives in /var/cores/ to blend with crash dumps.
2. The implant grabs the API key for management access by reading /etc/appweb/conf/auth/ and exfiltrating it.
3. It establishes a persistent reverse-shell via TLS to a C2 that hops every 24 hours through a domain-generation algorithm.
4. It enumerates configured tunnels — IPsec to peer firewalls, GlobalProtect to remote workers, MGT-tunnel to Panorama. From there, lateral movement.
5. It registers a custom job in PAN-OS's job scheduler so that the implant survives reboot and even the in-place upgrade if the upgrade does not flush /var/cores/.
6. SSL decryption certificates and cached HTTPS-decrypted flows are exfiltrated. This is the high-value blob: HR portal sessions, M365 traffic, Salesforce sessions, banking app traffic if your firewall MITM's it, all of it.

The implant is quiet. It does not encrypt. It does not ransom. It exfiltrates and persists. If your shop does not look proactively, you will not know you are owned.

#Detection commands — run these first, before patching

Run these from a console session on the PAN-OS box, ideally as a least-privileged read-only operator account. Don't use superuser for this — if the box is compromised, your superuser session may be observed.

Check the running PAN-OS version:

> show system info | match sw-version

Check if the captive portal is enabled:

> show running security-policy | match captive-portal
> show user-id captive-portal-state

If the second command returns anything other than "disabled," the bug is reachable from whichever zone the captive portal is configured to serve.

Check management-plane processes for unfamiliar children of appweb or mgmtsrvr:

> debug software show running processes

Look for any process whose parent is appweb (the management-plane web server) but whose name is not on the standard PAN-OS process list (useridd, varrcvr, sysd, logrcvr, sysdaemon, dha, etc.). Anything unfamiliar is a smoking gun.

Check /var/cores/ for files that don't look like crash dumps:

> debug shell
$ ls -la /var/cores/ /var/log/pan/cores/

A real crash dump is named _.tgz and is between 50MB and 500MB. Anything that doesn't fit that profile — especially anything executable, anything 1-10MB, anything ending in .so or .bin — is suspicious.

Check the job scheduler for unauthorized custom jobs:

> show jobs all

Anything you didn't add is suspicious. Note that the legitimate commit-all, auto-commit, and dynamic-update jobs are normal.

Check the syslog forwarding configuration for tampering:

> show config running syslog

The implant sometimes silently disables alert forwarding to your SIEM. If your SIEM has gone quiet from this firewall in the last week, that's the signal.

Check management-plane outbound TLS connections that you didn't initiate:

> debug shell
$ ss -tnp | grep -v ESTAB

Look for connections to unfamiliar IPs, especially anything resolving to a generic VPS provider (Hetzner, OVH, DigitalOcean, Vultr) on port 443 or 8443.

If any of the above turns up something you can't explain, stop and engage IR. Do not reboot. Do not push a config change. Snapshot the box's memory if you can (Palo Alto's tech support file will dump enough state to be useful), and bring in a team.

#Mitigation today, before the patch lands

Palo Alto's recommended workaround until the May 13/28 patches:

• Disable the User-ID Captive Portal entirely if you can:

> configure
  # set network virtual-router default protocol bgp [...skip — wrong subtree]
  # delete network user-id-agent captive-portal
  # commit

In the GUI: Network → User-ID Setup → Captive Portal → Disable.

• If you can't disable it (production guest WiFi reliance), restrict source-IP access to the captive portal endpoint with an inbound policy that only permits the corporate WAN ranges expected to land there. Block 0.0.0.0/0 from the captive portal ZONE explicitly. This is messy because the whole point of the captive portal is to handle unknown-source traffic, but at minimum you can block known-bad ASN ranges (Tor exit relays, common VPS providers, known scanner IPs).

• Implement a Threat-Prevention signature against the known exploit patterns. As of yesterday, the Threat Vault has IDs 94821 and 94823 for exploitation attempts against this CVE; subscribe to the dynamic update channel and ensure those signatures are in your active profile.

• Force re-authentication on all GlobalProtect users. If the management plane is owned, GlobalProtect session secrets may be too. Rotating now is cheap insurance.

• Rotate the management API key and the Panorama-to-firewall shared secret. If the implant has the API key, an attacker can issue commits remotely even after the patch. Rotation requires a Panorama-side update; coordinate with your network team.

#The patch order

1. Identify your most exposed firewall first — typically the perimeter device that does guest WiFi captive-portal work or the box doing external GlobalProtect. Patch this one first.
2. Patch in a maintenance window with HA failover staged. If you have HA, fail over to the secondary, patch the primary, validate, fail back, patch the secondary. Do not patch both halves of an HA pair simultaneously.
3. After patching, run the detection commands above again. Patching does not remove an existing implant. If the implant is in /var/cores/ or as a custom scheduler job, it will persist across the patch unless explicitly removed.
4. Move on to less-exposed boxes — internal segmentation firewalls, branch boxes, lab environments — once your perimeter is clean.
5. Last: patch your dev/lab Palo Altos. They're often forgotten, and an owned dev firewall is a stable foothold for an attacker who got in months ago.

The patch metadata from Palo Alto:

• PAN-OS 11.2.x → patched in 11.2.7-h2 (releases May 13)
• PAN-OS 11.3.x → patched in 11.3.4-h1 (releases May 22)
• PAN-OS 12.0.x → patched in 12.0.2-h1 (releases May 28)
• PAN-OS 11.0.x and earlier → out of mainstream support; advised migration to 11.2.7-h2

#What if you find evidence of compromise?

Stop reading and engage IR. The implant has root. The implant has been resident potentially since mid-April. Your decryption keys are gone. Your VPN secrets are gone. Your firewall is, at minimum, an uncategorizable risk and at maximum an active foothold inside your network that needs to be rebuilt from scratch — not patched, not cleaned, rebuilt.

The right sequence in that case:

1. Take the box out of the traffic path. Hot-failover to a known-good HA partner if you have one; otherwise, route around it temporarily through a different perimeter device.
2. Snapshot for forensics. Pull the tech-support file with request tech-support *before* you wipe.
3. Wipe and re-image from scratch. Do not trust an in-place upgrade to clean a compromised PAN-OS box. The implants we've seen survive in-place upgrades.
4. Rotate every secret that touched the box: SSL decryption keys, GlobalProtect session keys, syslog destination credentials, Panorama shared secret, SNMP communities, API tokens.
5. Hunt laterally. The captive-portal RCE is the front door; assume the attacker has at least begun lateral movement into the segments behind the firewall. Look for unusual outbound TLS from internal hosts to the same VPS-provider IP space the firewall implant called home to.
6. Notify per your incident plan. If you handle regulated data (PCI, HIPAA, GDPR-scope, state breach laws), the clock is ticking.

#What this means for your security budget

If the firewall you paid eighty thousand dollars for has an unauthenticated remote-code-execution bug in a default-on feature — and it took an external research team to find it before mass exploitation — what does that say about your security posture?

It says you bought defense in depth and got a single product. That one box has been your perimeter, your IDS, your VPN endpoint, your SSL inspection point, and your reporting fabric. When it falls, all of those fall together. The bug class (stack overflow in HTTP parameter parsing in 2026) is embarrassing for a vendor pricing themselves at the platinum tier.

This is not a Palo Alto-specific problem. Cisco ASA, Fortinet FortiGate, and Check Point all have CVE histories that look exactly the same — unauthenticated RCE in management-plane HTTP parsers, found years after the bug shipped, exploited in the wild before the patch lands. The lesson is that perimeter appliances, regardless of vendor, are themselves the highest-value targets in your environment, and a layered defense that doesn't account for the perimeter being owned is not actually layered.

#What Valtik does about this

If you're a small business or a single-IT-person shop running a Palo Alto firewall, you don't have a Unit 42 retainer and you don't have an incident-response team on call. You have a config interface, a quarterly upgrade cycle, and a whole lot of hope. Valtik's audit service is built for exactly that profile: we look at your firewall config, your captive portal exposure, your User-ID setup, and your management-plane access controls, and we tell you in plain English what to fix this week. We're not a SIEM vendor and we're not selling you a quarterly retainer for the rest of your life. We're a focused, one-time, fixed-price engagement.

If your IT person just learned about CVE-2026-0300 from this post, send them the link. Then book a free 15-minute config review at valtikstudios.com/free-check. We'll tell you whether the captive portal is reachable, whether the User-ID setup is exploitable in your specific config, and whether the patch order I laid out above will work for your topology.

The next disclosed PAN-OS RCE is not going to be six months from now. It's going to be six weeks from now. Anthropic Mythos and Google Big Sleep have been shipping CVEs at a rate the vendor patch pipeline has never had to absorb before. The half-life of "your firewall is safe today" keeps getting shorter. Build for it.

---

Sources cited:

• Palo Alto Networks Security Advisory PAN-SA-2026-0300 (May 6, 2026)
• BleepingComputer: "Palo Alto Networks warns of firewall RCE zero-day exploited in attacks" (May 6, 2026)
• Help Net Security: "Palo Alto firewalls vulnerability exploited" (May 6, 2026)
• Cybersecurity News: "Critical Palo Alto Firewalls Vulnerability Exploited in the Wild to Gain Root Access" (May 6, 2026)
• The Cyber Express: "PAN-OS Flaw CVE-2026-0300 Exposes Firewalls to Remote Code Execution" (May 6, 2026)
• The Hacker News: "Palo Alto PAN-OS Flaw Under Active Exploitation Enables Remote Code Execution" (May 6, 2026)