CVE-2026-0300: The Captive Portal You Didn't Know You Had

Palo Alto renamed Captive Portal to Authentication Portal a few major releases back. The feature is still there. Plenty of security teams search their configs for "captive portal," come up empty, and conclude they aren't running it. Many of them are wrong.

CVE-2026-0300 is an unauthenticated buffer overflow in the PAN-OS User-ID Authentication Portal, which is the same feature under a newer name. No credentials required. A buffer overflow in this subsystem gets you root on the firewall. There is no fixed PAN-OS build available as of this writing, and exploitation has been observed in the wild.

Why the naming matters operationally

Renames don't propagate cleanly through an organization. Vendor documentation gets updated. Whether your internal runbooks, wiki pages, and dashboards reflect the change is a separate question, and the answer is often no.

When somebody asks "are we running Captive Portal?" and the answer comes back "no, we deprecated that years ago," there's a reasonable chance the person answering is looking at a rule named captive_portal and missing six interfaces with enable-user-id flipped on. Authentication Portal and Captive Portal are the same feature with different labels in the GUI. If you have any of these conditions, you have the others:

• A zone with Enable User Identification turned on
• An Authentication Portal Settings entry under Device → User Identification
• Any policy with a User-ID source that resolves via portal redirect

PAN-OS documentation moved to the new terminology around the 9.x release. If your internal docs still use the old name, they're out of date.

The 30-second check

Before any compensating-control discussion, before any patch-window negotiation, confirm whether you're actually exposed.

In the PAN-OS web UI, go to Device → User Identification → Authentication Portal Settings. If "Enable Authentication Portal" is checked, note which interfaces it serves. Then cross-reference with Network → Zones: any zone with "Enable User Identification" turned on that lives behind one of those interfaces has the vulnerable component reachable from anything that can reach that zone. That includes the inside of segments you'd otherwise consider trusted. The source of traffic doesn't matter to the vulnerability.

If the box is checked and an external or partner-facing zone touches it, treat it as an active incident.

"Out-of-band" doesn't mean today

Palo Alto's standard pattern for an unauthenticated RCE in a perimeter component is a hotfix train rather than a single release. Hotfixes drop per-version, per-train (10.1, 10.2, 11.0, 11.1, 11.2), and they don't all land on the same day. First builds typically appear within days of disclosure for the most common LTS versions. Older trains and feature releases can follow days or weeks later. Customers running Panorama-managed fleets under strict change-window discipline are realistically looking at weeks of work to get clean.

Public discussion of the CVE will quiet down once the first hotfix ships. Your environment won't be done at that point.

The vendor cascade

PAN-OS doesn't only run on appliances. Prisma Access tenants run PAN-OS underneath. Customers consuming Palo Alto's cloud-delivered SASE are subject to the same patch cycle for the multi-tenant infrastructure they don't operate themselves. Federal customers running cloud-delivered GlobalProtect edges have a scheduling problem they can't influence directly.

"We're not running PAN-OS on-prem" doesn't get you out of the patch cycle.

What this post intentionally leaves out

A few things deserve more depth than a public post can responsibly carry:

• Compensating controls that actually work, with the specific configuration changes to apply while you wait on hotfixes. There are several variants depending on whether Authentication Portal is required for your User-ID flow in the first place.
• What "trusted internal" really means when an unauthenticated pre-auth code path on the firewall accepts traffic from your campus VLANs the same way it accepts it from a coffee shop overseas. The threat model has been wrong about this for a long time, and this CVE makes it harder to ignore.
• Federal directive math, including how to read a likely CISA emergency directive against your existing change-management calendar and your AO's risk tolerance without freelancing your own answer.
• Detection guidance for flow logs, GlobalProtect logs, and management-plane traffic if you suspect exposure before you flipped the right knob.

We've packaged that into a working advisory PDF with the technical depth one of our engineers would walk a customer through on a brief call. If you want it, request it here. We read every request and respond directly.

In the meantime, run the 30-second check. The naming gotcha is doing real damage right now, and ruling it out costs nothing.