Palo Alto Networks PSIRT published an advisory yesterday (May 5, 2026) for CVE-2026-0300, a buffer overflow in PAN-OS's User-ID Authentication Portal — historically and still colloquially called "Captive Portal." The flaw lets an unauthenticated, unprivileged attacker reachable on the network execute arbitrary code with root privileges on PA-Series (hardware) and VM-Series (virtual) firewalls by sending specially crafted packets to the portal. Palo Alto rates this CRITICAL with CVSS-BT 9.3, marks the suggested urgency as HIGHEST, and — most importantly for operators — sets the exploit-maturity field to ATTACKED, with limited in-the-wild exploitation already observed against portals exposed to untrusted IP ranges or the public internet. Patches are not available for every affected branch yet; fix ETAs span May 13 and May 28, 2026, leaving a 7-22 day window (from this bulletin's May 6 publication date) where mitigation is the only available action for some builds. Prisma Access, Cloud NGFW, and Panorama appliances are not affected. The bug only matters on PA-Series and VM-Series firewalls that have User-ID Authentication Portal enabled.
Framing note: this is a vulnerability in a network firewall, in a portal that is sometimes intentionally exposed to the internet (for guest-Wi-Fi auth, BYOD onboarding, and external user-identity mapping in zero-trust deployments). When the device that is supposed to enforce your perimeter has pre-auth RCE-as-root, the blast radius is whatever sits behind it: traffic visibility, MITM positioning, lateral pivot, and persistence that survives endpoint reimaging. This is a drop-everything bulletin for any organization with an Authentication Portal in the affected version range.
Three things stack: (1) the vulnerability
is pre-auth, root-level, network-reachable, low-complexity,
and Palo Alto's CVSS 4.0 metadata flags it as
Automatable: YES — the worst-case shape for an
edge appliance; (2) Palo Alto's own
advisory says limited exploitation has already been
observed in the wild, before public disclosure;
(3) patched builds are not yet shipping
for several affected branches, with ETAs of May 13 and
May 28. For 7-22 days depending on which build you run,
the only available mitigation is to restrict Authentication
Portal access to explicitly trusted internal source IPs and
zones (not merely a broad "inside" zone) or to disable the
portal entirely. The Threat Prevention signature (PAN-OS
11.1+) helps, but only if you have the subscription and
only on those branches. If your portal is exposed to the
internet right now, treat it as exposed to active
exploitation and act on the workaround within hours, not
days.
Priorities, by environment
Triage on three axes: is the Authentication Portal enabled, is it reachable from the internet or any untrusted segment, and which PAN-OS branch are you on (because the branch determines both your patch ETA and whether the Threat Prevention signature is available to you).
| Priority | Workload | Why |
|---|---|---|
| Highest | PA-Series or VM-Series with Authentication Portal exposed to the internet or any untrusted network | This is the configuration where in-the-wild exploitation has been observed. CVSS-BT 9.3. Apply the workaround within hours: restrict portal access to trusted internal zones, or disable the portal entirely if not required. Apply the Threat Prevention signature (PAN-OS 11.1+) immediately. Patch as soon as your branch's hotfix lands. |
| Higher | PA-Series or VM-Series with Authentication Portal enabled, restricted to internal trusted zones | CVSS-BT drops to 8.7 HIGH per Palo Alto's own scoring. Still a pre-auth RCE-as-root reachable from anyone on the trusted network. An insider, a compromised endpoint, a guest network with a routing mistake, or a misconfigured internal segment can all reach it. Apply the Threat Prevention signature, plan the patch upgrade for as soon as your branch's hotfix is available, and consider disabling the portal during the 7-22 day window if operationally feasible. |
| Higher | PAN-OS 10.2 deployments with Authentication Portal enabled (any exposure) | The Threat Prevention signature mitigation is documented as available to PAN-OS 11.1 and above. PAN-OS 10.2 customers do not get that fallback; the workaround (restrict or disable portal) is the only mitigation until a 10.2 hotfix ships. Several 10.2 hotfix ETAs are 2026-05-28, the back of the patch schedule. |
| Medium | PA-Series or VM-Series with Authentication Portal disabled or not configured | Not exposed. Verify the portal is genuinely disabled (Device > User Identification > Authentication Portal Settings -> Enable Authentication Portal unchecked); patch on the normal hotfix cycle when the build for your branch ships. Re-confirm portal-disabled state after any future config changes or HA failover. |
| Lower | Prisma Access, Cloud NGFW, Panorama | Not affected by this CVE. No action required. (Panorama administrators should still patch the firewalls Panorama manages, on the schedules above.) |
Categorization source: Bulletin's framing based on Palo Alto's CVSS-BT scoring (9.3 internet-exposed, 8.7 trusted-network-only) and the differential availability of the Threat Prevention signature across PAN-OS branches.
Am I affected?
Quick checks (PAN-OS web UI and CLI)
1. Is the Authentication Portal enabled? In the PAN-OS web UI, navigate to:
Device > User Identification > Authentication Portal Settings
Look for the Enable Authentication Portal checkbox. If unchecked, the device is not affected by CVE-2026-0300 in any meaningful sense — patch on the normal cycle when your branch's hotfix ships and re-verify the portal-disabled state stays disabled. If checked, you are affected. Continue.
2. What PAN-OS branch and build are you on? From the CLI:
show system info | match sw-version
Or from the web UI: Dashboard widget "General Information" shows Software Version. Cross-reference against the Affected and Fixed Versions block above. If your build is at or above the patched build for your branch, you are patched. If not, you are vulnerable; proceed to mitigation.
3. Where is the Authentication Portal interface reachable from? The portal listens on the IP address configured under the Authentication Portal Settings, constrained by the security policies that govern the zone the interface sits in. The exposure question is: from which source zones is traffic to the portal interface allowed by your policy? If the answer includes any untrust / external / internet zone, the portal is internet-exposed for the purposes of CVSS-BT 9.3 and CVE-2026-0300 mitigation priority. Review:
Policies > Security
Filter for rules whose destination is the portal interface IP or a zone containing it. If you have an external-source-zone rule allowing traffic to the portal, that is the rule the workaround needs to address.
Is the Threat Prevention signature mitigation available to me?
The Threat Prevention signature was made available by 2026-05-05 to all customers running PAN-OS 11.1 and above. To qualify, you need: (a) PAN-OS 11.1, 11.2, or 12.1; (b) an active Threat Prevention subscription; (c) the Applications and Threats content updates on automatic install or recent manual install; (d) a Vulnerability Protection profile applied to the Security policy rule that governs traffic to the Authentication Portal. PAN-OS 10.2 customers cannot rely on the signature mitigation per Palo Alto's published guidance and must use the workaround.
Response, by priority
If the Authentication Portal is internet-exposed (Highest priority)
- Immediate workaround: restrict Authentication Portal access to explicitly trusted internal source IPs / address groups, not merely a broad "inside" zone. Edit the Security policy rule(s) permitting traffic to the Authentication Portal interface and constrain both the source zone and the source address — Palo Alto's own advisory cites best practice as "restricting access to only trusted internal IP addresses", not merely "trusted zone." A broad inside zone in many real deployments still includes guest segments, BYOD subnets, lab networks, or misconfigured VLANs that should not have portal reach. Use an Address Group of explicit user subnets and reference it in the rule's source-address field. Refer to Palo Alto's Live Community article on securing the management interface (Step 6) and the knowledgebase article for the exact procedure. Commit, then verify from an external source that the portal is no longer reachable, and verify from an in-scope-but-outside-the-address-group source that the rule's source-address constraint actually blocks traffic (not just the zone constraint).
- Apply the Threat Prevention signature (PAN-OS 11.1+ only). Confirm the latest Applications and Threats content update is installed (verify in the device's Dynamic Updates page; the signature for CVE-2026-0300 is delivered through Applications and Threats content, not the Antivirus package). Confirm a Vulnerability Protection profile is applied to the Security policy rule governing traffic to the Authentication Portal interface — the Vulnerability Protection profile is what causes the firewall to act on threat signatures inline. The signature provides defense-in- depth on top of the workaround; it is not a substitute for the workaround.
- If the firewall has been internet-exposed for any meaningful window before applying the workaround, treat it as potentially compromised. Limited exploitation has been observed in the wild. Even though Palo Alto has not published IOCs at time of writing, a firewall that has been exposed during the active-exploitation window warrants investigation: review traffic logs and management- plane logs for unusual activity against the portal interface (high-rate or malformed requests are suggestive), review System logs for unexpected daemon restarts or crashes, review Threat logs for any signature hits matching the new CVE-2026-0300 detection once it lands, and check whether any unexpected outbound connections originate from the firewall management plane. Engage Palo Alto Unit 42 or your IR vendor if you find signs of compromise. Root on a firewall is not a workstation incident — preserve logs and configuration before any reboot or factory reset; capture a tech-support file and export the running config to off-device storage first, since prior PAN-OS incidents (notably the post-exploitation activity observed around CVE-2024-3400) have shown that post-compromise persistence and forensic-relevant artifacts can be lost or obscured by a routine reboot. Consider out-of-band forensics before remediation.
- Apply the patched build for your branch as soon as Palo Alto ships it (per the ETA table above). After upgrade, verify the running version matches the patched build, and re-confirm portal accessibility against your intended exposure model.
- Do not relax the workaround after patching unless you have a clear operational reason to re-expose the portal. The "least-privilege exposure" posture Palo Alto cites — portal restricted to trusted internal IPs — is the long-term recommended best practice independent of this CVE.
If the Authentication Portal is restricted to trusted internal zones (Higher priority)
- Apply the Threat Prevention signature (PAN-OS 11.1+ only), as above. PAN-OS 10.2 deployments need to wait for the patched build and may want to consider disabling the portal during the wait.
- Plan the patched-build upgrade for the first available hotfix window for your branch. Hotfix ETAs are 2026-05-13 or 2026-05-28; check Palo Alto's advisory page for live status before each maintenance window.
- Decide whether to disable the portal during the wait. CVSS-BT 8.7 means a network-adjacent attacker (on a compromised endpoint, a misconfigured zone, a guest network with a routing mistake, an insider, or through a separate initial-access vector) still gets pre-auth RCE-as-root. If the portal is in active operational use for identity mapping, the cost of disabling it during the patch window may exceed the residual risk; if it is enabled but rarely actually used, disabling it for 7-22 days is a cheap mitigation.
- Audit the portal's effective reachability — by source address, not just by source zone. "Trusted internal" is not a single zone in most deployments, and a zone-only restriction can still be too broad. Verify the actual Security policy rule permitting traffic to the portal interface, confirm both the source zones and source-address constraints genuinely reflect your trust model, and confirm no untrust / external / guest segment can reach the portal either directly or via routing through a more permissive zone. Pay particular attention to legacy permissive rules from years ago and to address objects that have grown broader than originally intended.
If the Authentication Portal is disabled (Medium priority)
- Confirm the portal is genuinely disabled in Authentication Portal Settings. Check both primary and passive HA peers; configuration drift between HA pairs is a common root cause of "we thought it was off."
- Patch on the normal hotfix cycle when the build for your branch ships. CVE-2026-0300 specifically is not actionable on this device, but the upgrade still clears the CVE from your inventory and any future re-enabling of the portal is safe.
- Add Authentication Portal Enabled to your config- drift detection. If Panorama or your config management raises an alert when the portal flips back on, you avoid the failure mode where someone enables it for a short-term need and the deployment quietly slides into the affected configuration.
The broader pattern
A few observations worth flagging in the context of this Bulletin's series:
First, this is another exploited PAN-OS internet-facing management/portal-plane incident in a short window, following CVE-2024-3400 (GlobalProtect command injection, April 2024 — pre-auth, unauthenticated RCE-as-root, the closest shape to CVE-2026-0300) and the CVE-2024-0012 + CVE-2024-9474 "Pots and Pans" chain (November 2024 — authentication bypass on the management web interface plus a paired privilege-escalation, exploited together to reach root). The individual bugs are not all the same shape, but the operational pattern is: a PAN-OS portal that is sometimes intentionally exposed to the internet, vendor advisory landing with active exploitation already observed, patches staggered or initially incomplete. Operators who handle PAN-OS firewalls should treat "exploited PAN-OS portal/management-plane CVE" as a recurring threat-model entry, not a one-off.
Second, the patched-build-staggered-over-three-weeks pattern is increasingly common for edge-appliance vendors and meaningfully changes operator response. The advisory, the partial Threat Prevention signature mitigation, and the workaround all need to land within hours; the patches themselves trail by 7-22 days per branch. Plan operationally for "live with mitigation for 2-3 weeks" rather than "patch this week."
Third, this fits the broader May 2026 patch landscape: cPanel CVE-2026-41940 (April 28, exploited in the wild, ransomware payloads), Copy Fail CVE-2026-31431 (April 29, CISA KEV, WSL2 implications), DAEMON Tools supply-chain (May 5, Kaspersky), Apache HTTPD CVE-2026-23918 (May 4, narrow exposure but real RCE chain), and now PAN-OS. May 2026 is shaping up as the noisiest patch month since Log4Shell-era for operators with diverse stacks. Triage ruthlessly; this PAN-OS issue belongs at the top of the list for any organization with the affected configuration.
At time of writing: Palo Alto has not published technical details of the buffer overflow, IOCs, or threat-actor attribution. CISA had not added CVE-2026-0300 to the KEV catalog as of publication; monitor the KEV catalog for change. No public PoC exists. Unit 42 has not, at time of writing, published a detailed campaign analysis. Targeting profile of the observed exploitation is not public — whether this is broad opportunistic scanning, a targeted nation-state campaign similar to the 2023-2024 edge-device targeting reported across multiple firewall vendors, or something else, is not yet established. The bulletin will be updated as those land. The principal action — restrict portal access to explicitly trusted internal source IPs, apply the Threat Prevention signature on PAN-OS 11.1+, patch when the hotfix ships — does not depend on those details and should not wait on them.
If you run a PA-Series or VM-Series firewall with User-ID Authentication Portal enabled: restrict portal access to explicitly trusted internal source IPs / address groups (not merely a broad "inside" zone) now, apply the Threat Prevention signature on PAN-OS 11.1+, plan the patched-build upgrade for May 13 or May 28 (per branch and hotfix, both anchored to this bulletin's May 6 publication date), and treat any firewall that has been internet-exposed during the active-exploitation window as potentially compromised. Do not wait on a public PoC or a CISA KEV listing — Palo Alto's own advisory says exploitation has already been observed. Panorama itself is not affected, but Panorama-managed PA / VM firewalls still need config review and patch tracking on the schedule above. Prisma Access and Cloud NGFW are not affected by this CVE.