CVE-2026-0300: Root RCE in the User-ID Authentication Portal, exploited as a zero-day

What it is

The User-ID Authentication Portal, also called Captive Portal, is the web page a firewall shows to map an IP address to a username, typically for guest Wi-Fi or for users the firewall can’t identify any other way. It’s off by default.

On vulnerable versions, the portal service has a buffer overflow. Specially crafted packets let an attacker run code as root on PA-Series and VM-Series firewalls, without credentials and without any user interaction. Unit 42 saw the shellcode injected into an nginx worker process.

This was a true zero-day. Exploitation started around 9 April, nearly four weeks before Palo Alto published the advisory, and fixed versions only arrived a week after that.

Am I affected?

You’re exposed only if both are true on a vulnerable PAN-OS version:

1. Authentication Portal is enabled. Check Device > User Identification > Authentication Portal Settings, then Enable Authentication Portal. This applies to both transparent and redirect modes.
2. Response pages are reachable from untrusted networks. An interface management profile with Response Pages enabled is attached to a Layer 3 interface in a zone that internet or other untrusted traffic can reach. Check Network > Interfaces > the interface > Advanced > Management Profile.

The second condition is the one to look for. Enabling response pages on an outside interface is an easy mistake to make when setting up captive portal or block pages, and it puts the portal on the internet.

Palo Alto scores the issue 9.3 when the portal is internet-facing and 8.7 when it’s limited to trusted internal addresses. Prisma Access, Cloud NGFW and Panorama are not affected.

What to do

1. Upgrade to a fixed hotfix on your branch (table above). As always, prefer the newest hotfix, since later advisories need newer builds.

2. Until you can upgrade, close the exposure:

• Disable Response Pages in every interface management profile attached to an interface in an untrusted or internet zone. Keep them only on internal interfaces where real users need them.
• Restrict the Authentication Portal to trusted zones, or disable it entirely if you don’t use it.
• With a Threat Prevention subscription, enable Threat ID 510019 (Applications and Threats content 9097-10022 or later). The signature needs PAN-OS 11.1 or later to work.

3. If your portal was internet-facing between 9 April and your fix, hunt for compromise (below). A root-level compromise of a firewall can’t be cleaned in place with confidence. If you find evidence, contact Palo Alto support about rebuilding the device, and treat everything stored on the firewall as exposed:

• the User-ID / LDAP service account (the attackers used the firewall’s own AD credentials for enumeration)
• local admin passwords and API keys
• IPsec pre-shared keys, certificates and private keys

Detection

The attackers cleaned up after themselves, so look for what’s missing as well as what’s there:

• Gaps in crash data. Unit 42 saw crash kernel messages, nginx crash entries and core dump files deleted right after exploitation. Missing crash records around a time the portal was under load are a warning sign.
• Files on the firewall at the paths listed below. Checking them needs Palo Alto support or a tech support file review, since PAN-OS doesn’t give you a shell.
• Outbound connections from the firewall itself to the internet, especially to the IPs below or to port 8000. A firewall rarely initiates connections to random hosts.
• Active Directory queries from the User-ID service account against the domain root and DomainDnsZones that don’t match normal User-ID behavior.
• Unexpected HA failovers. In one case the second firewall of the pair was exploited after it became active.
• Threat logs for Threat ID 510019 once the signature is enabled.