← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-0300 · CWE-787 · Disclosed 2026-05-06

A buffer overflow vulnerability in the User-ID™ Authentication Portal

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a land mine hidden in an optional side gate, not a crack in every firewall

CVE-2026-0300 is an out-of-bounds write in the PAN-OS User-ID Authentication Portal, formerly Captive Portal, that can let an unauthenticated attacker send crafted network traffic and get root RCE on affected PA-Series and VM-Series firewalls. The affected trains span 12.1, 11.2, 11.1, and 10.2, but the advisory is explicit that exposure exists only when the User-ID Authentication Portal is enabled and an interface management profile with response pages is reachable from an untrusted or internet-facing zone.

The vendor's CRITICAL label is technically defensible, but fleet-wide it overstates how many enterprises are actually one packet away from compromise. The real story is narrower exposure but worse consequences: this is not every PAN-OS host, yet for the subset with the portal exposed, the combination of no auth, root on a perimeter appliance, KEV listing, and observed exploitation makes it an emergency.

"Pre-auth root RCE on a firewall is nasty, but only exposed Captive Portals are in the blast zone."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find exposed User-ID portals

Attackers enumerate PAN-OS edge devices with internet scanning using tools such as zgrab, masscan, or commercial search datasets from Censys and Shodan. The useful target set is not just 'any PAN-OS box' but firewalls exposing the Authentication Portal path from an untrusted zone.
Conditions required:
  • Unauthenticated remote network access to the target
  • Target is PA-Series or VM-Series running an affected PAN-OS build
  • User-ID Authentication Portal is enabled and reachable from untrusted or public networks
Where this breaks in practice:
  • The feature is non-default in many deployments
  • Many enterprises keep the portal internal-only or disable it entirely
  • Censys says the potentially vulnerable subset is much smaller than the overall internet-facing PAN-OS population
Detection/coverage: External attack-surface tools and ASM platforms can identify exposed PAN-OS instances; generic vuln scanners may over-report version-only matches if they do not validate portal exposure.
STEP 02

Trigger the buffer overflow

The attacker delivers crafted packets to the portal service and abuses the out-of-bounds write to gain code execution as root. Public exploit material has appeared on GitHub, reducing the lift from bespoke exploit development to weaponization and adaptation.
Conditions required:
  • Reachability to the vulnerable portal service
  • Affected version remains unpatched or unmitigated
Where this breaks in practice:
  • Exploit reliability against appliance targets can vary by branch and build
  • Portal access restrictions or disabled response pages break the path before code execution
Detection/coverage: Palo Alto says customers with Threat Prevention can block this via Threat ID 510019 from Applications and Threats content version 9097-10022; network IDS coverage will depend on seeing the exact protocol path.
STEP 03

Establish persistence and hide the hit

Unit 42 observed successful RCE followed by shellcode injection into the nginx worker process and immediate anti-forensics. The operators cleared crash kernel messages, removed nginx crash entries, and deleted core dump artifacts to reduce the chance of post-incident reconstruction.
Conditions required:
  • Successful code execution on the firewall
Where this breaks in practice:
  • Short dwell times and crash artifacts can still betray failed attempts
  • Organizations forwarding firewall logs off-box retain a better record than appliance-local logging alone
Detection/coverage: Look for unexpected process behavior, missing local crash artifacts, sudden log gaps, and configuration or service anomalies around the time of inbound portal traffic spikes.
STEP 04

Pivot inward from the perimeter

Observed post-exploitation tooling included EarthWorm and ReverseSocks5 for tunneling, followed by Active Directory enumeration using credentials likely obtained from the firewall. That turns a feature-specific firewall bug into a broader identity and internal access problem.
Conditions required:
  • Firewall stores or can access useful credentials
  • Compromised device has network adjacency to internal services
Where this breaks in practice:
  • Segmentation, egress controls, and credential hygiene can limit follow-on movement
  • Not every compromised firewall yields reusable AD-facing credentials
Detection/coverage: Monitor for new outbound tunnels from firewall IPs, anomalous directory lookups, and post-compromise traffic patterns inconsistent with normal control-plane behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusYes. Palo Alto marks exploit maturity as ATTACKED and says limited exploitation targeted exposed User-ID Authentication Portals; Unit 42 observed unsuccessful attempts starting 2026-04-09 and successful RCE by 2026-04-16.
KEV statusKEV-listed. NVD references the CISA KEV entry for CVE-2026-0300; Rapid7 notes it was added on 2026-05-06.
PoC availabilityPublic exploit material exists. Example: GitHub repo 0xBlackash/CVE-2026-0300. Treat this as attacker enablement, not proof of reliable one-shot exploitation across all branches.
EPSSUser-supplied EPSS is 0.04536 (~4.5%). Secondary aggregators place it around the 89th percentile. That is not sky-high by commodity-web scale, but KEV status matters more here than EPSS.
CVSS pictureThere is a scoring split: NVD CVSS v3.1 = 9.8 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), while the vendor CVSS v4 base threat shown in NVD is 9.3 CRITICAL. Both assume straight network reachability; neither fully captures the exposure gating.
Required exposure conditionsThe advisory says both must be true: User-ID Authentication Portal enabled and an interface management profile with response page enabled attached where untrusted or internet traffic can ingress.
Affected versions12.1 <12.1.4-h5 or <12.1.7; 11.2 <11.2.4-h17 / <11.2.7-h13 / <11.2.10-h6 / <11.2.12; 11.1 <11.1.4-h33 / <11.1.6-h32 / <11.1.7-h6 / <11.1.10-h25 / <11.1.13-h5 / <11.1.15; 10.2 <10.2.7-h34 / <10.2.10-h36 / <10.2.13-h21 / <10.2.16-h7 / <10.2.18-h6.
Fixed versionsUpgrade to the first fixed build in your train: 12.1.4-h5 / 12.1.7, 11.2.4-h17 / 11.2.7-h13 / 11.2.10-h6 / 11.2.12, 11.1.4-h33 / 11.1.6-h32 / 11.1.7-h6 / 11.1.10-h25 / 11.1.13-h5 / 11.1.15, 10.2.7-h34 / 10.2.10-h36 / 10.2.13-h21 / 10.2.16-h7 / 10.2.18-h6.
Exposure populationCensys sees roughly 263,000 internet-exposed PAN-OS hosts overall, but says the subset with the vulnerable Authentication Portal externally reachable is much smaller. Rapid7 cited roughly 225,000 internet-facing PAN-OS instances overall; TechRadar, citing Shadowserver, mentioned about 5,800 exposed VM-Series systems.
Discovery / reportingThe vendor says the bug was discovered in production use and credits Palo Alto's Deep Product Security Research Team with threat-research support from Unit 42 and Xpanse ILI.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.8/10)

The decisive downward pressure is reachability gating: exploitation requires a specific, non-universal PAN-OS feature to be enabled and reachable from an untrusted zone, which materially narrows the exposed population. What keeps this firmly in HIGH instead of MEDIUM is the opposite amplifier: KEV-listed, pre-auth root RCE on a perimeter security appliance with observed post-exploitation pivoting.

HIGH Active exploitation and KEV status
HIGH Exposure prerequisite: Authentication Portal must be enabled and reachable
MEDIUM Estimated exposed population across enterprise fleets

Why this verdict

  • Baseline starts near vendor CRITICAL because this is unauthenticated network RCE as root on a perimeter device, with no user interaction.
  • Downgrade for feature gating: the attack path is real only when User-ID Authentication Portal is enabled *and* response pages are exposed on an ingress interface. That is a meaningful reduction from 'all PAN-OS firewalls.'
  • Downgrade for reachable population: Censys explicitly says the vulnerable subset is much smaller than the overall internet-facing PAN-OS population. Vendor CVSS assumes raw network reachability; real fleets often do not expose this portal externally.
  • Upgrade back up for exploitation evidence: Palo Alto marks it ATTACKED, Unit 42 published observed tradecraft, and CISA KEV means defenders should assume adversaries are already scanning for the exposed subset.
  • Hold at HIGH, not MEDIUM: once the preconditions are met, the blast radius is ugly—root on a firewall, tunneling, anti-forensics, and AD-focused follow-on activity are all credible and observed.

Why not higher?

I am not leaving this at fleet-wide CRITICAL because the real-world target pool is narrower than the headline score implies. This is not a bug in every exposed PAN-OS service; it is a bug in a specific portal configuration, and that prerequisite compounds with external reachability requirements.

Why not lower?

I am not pushing this to MEDIUM because the attacker position is still unauthenticated remote once the portal is exposed, and the impact is full root on the firewall. KEV listing and observed exploitation erase any comfort you might get from the lower-than-expected EPSS.

05 · Compensating Control

What to do — in priority order.

  1. Restrict portal access to trusted zones only — Apply Palo Alto's workaround immediately, within hours, because this CVE is KEV-listed and actively exploited. Remove Authentication Portal reachability from any untrusted or internet-ingress interface, and disable response pages on those interfaces so the exploit path is no longer externally reachable.
  2. Disable User-ID Authentication Portal if unused — If the feature is not operationally required, shut it off immediately, within hours. This is the cleanest mitigation because it removes the vulnerable service rather than trying to filter around it.
  3. Enable Threat ID 510019 — Where supported, turn on Palo Alto Threat ID 510019 from Applications and Threats content version 9097-10022 immediately, within hours. This gives you a vendor-supplied network-layer block, but note the decoder support caveat for older branches.
  4. Hunt for post-compromise on exposed firewalls — Treat every internet-exposed portal as suspect and start review immediately, within hours, for anti-forensics, outbound tunnels, and AD enumeration indicators. This matters because Unit 42 observed log cleanup and tunneling after exploitation, which means waiting for a clean patch window is the wrong mental model.
  5. Patch to the first fixed build in-train — Move each affected branch to its first fixed release as soon as change control allows, with exposed-and-enabled systems handled first. For this HIGH verdict the formal remediation window is wider, but KEV reality means your emergency cases should not wait for routine maintenance.
What doesn't work
  • MFA does not help because the attack is pre-auth against the portal service itself.
  • EDR on endpoints does not stop initial compromise of the firewall appliance; the hit lands on the security device, not a Windows or Linux user endpoint.
  • Version-only scanner findings are not enough for prioritization because a matching PAN-OS build without the portal exposed is not on the same risk tier.
  • Generic internet ACLs that still leave response pages reachable on an untrusted ingress interface do not remove the vulnerable path.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation that can reach the PAN-OS management interface over HTTPS. Invoke it as python3 panos_cve_2026_0300_check.py --host 10.0.0.1 --api-key <APIKEY>; it needs a PAN-OS XML API key with read access, and it does not require shell access to the firewall.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-0300 exposure checker for PAN-OS
# Checks PAN-OS version and attempts to infer whether User-ID Authentication Portal
# / Captive Portal exposure is configured from exported configuration.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

import argparse
import re
import sys
import ssl
import urllib.parse
import urllib.request
import xml.etree.ElementTree as ET
from distutils.version import LooseVersion

FIXED = {
    '12.1': ['12.1.4-h5', '12.1.7'],
    '11.2': ['11.2.4-h17', '11.2.7-h13', '11.2.10-h6', '11.2.12'],
    '11.1': ['11.1.4-h33', '11.1.6-h32', '11.1.7-h6', '11.1.10-h25', '11.1.13-h5', '11.1.15'],
    '10.2': ['10.2.7-h34', '10.2.10-h36', '10.2.13-h21', '10.2.16-h7', '10.2.18-h6'],
}

AFFECTED_BRANCHES = ('12.1', '11.2', '11.1', '10.2')


def parse_args():
    ap = argparse.ArgumentParser(description='Assess PAN-OS exposure to CVE-2026-0300')
    ap.add_argument('--host', required=True, help='PAN-OS management IP or hostname')
    ap.add_argument('--api-key', required=True, help='PAN-OS XML API key')
    ap.add_argument('--port', default='443', help='Management HTTPS port (default: 443)')
    ap.add_argument('--insecure', action='store_true', help='Disable TLS certificate verification')
    return ap.parse_args()


def http_get(url, insecure=False):
    ctx = None
    if insecure:
        ctx = ssl.create_default_context()
        ctx.check_hostname = False
        ctx.verify_mode = ssl.CERT_NONE
    req = urllib.request.Request(url, headers={'User-Agent': 'noisgate-cve-2026-0300-check/1.0'})
    with urllib.request.urlopen(req, context=ctx, timeout=20) as resp:
        return resp.read()


def api_url(host, port, params):
    q = urllib.parse.urlencode(params)
    return f'https://{host}:{port}/api/?{q}'


def fetch_system_info(host, port, key, insecure=False):
    cmd = '<show><system><info/></system></show>'
    url = api_url(host, port, {'type': 'op', 'cmd': cmd, 'key': key})
    raw = http_get(url, insecure=insecure)
    root = ET.fromstring(raw)
    if root.attrib.get('status') != 'success':
        raise RuntimeError('API call for system info failed')
    sw = root.find('.//sw-version')
    hn = root.find('.//hostname')
    return (sw.text.strip() if sw is not None and sw.text else None,
            hn.text.strip() if hn is not None and hn.text else host)


def fetch_running_config(host, port, key, insecure=False):
    url = api_url(host, port, {'type': 'export', 'category': 'configuration', 'key': key})
    return http_get(url, insecure=insecure).decode('utf-8', errors='ignore')


def branch_of(version):
    m = re.match(r'^(\d+\.\d+)', version)
    return m.group(1) if m else None


def normalize(v):
    return v.lower().strip()


def version_ge(a, b):
    # LooseVersion handles PAN-OS hotfix strings well enough for audit use.
    return LooseVersion(normalize(a)) >= LooseVersion(normalize(b))


def is_version_patched(version):
    branch = branch_of(version)
    if branch not in FIXED:
        return None
    return any(version_ge(version, fixed) for fixed in FIXED[branch])


def is_version_in_scope(version):
    branch = branch_of(version)
    return branch in AFFECTED_BRANCHES


def infer_portal_exposure(config_text):
    t = config_text.lower()

    # Heuristic indicators only; PAN-OS config structures vary by release.
    portal_enabled = False
    if 'authentication-portal' in t or 'captive-portal' in t:
        # Try to avoid false positives from docs/comments by requiring nearby enable-like markers.
        portal_enabled = bool(re.search(r'(authentication-portal|captive-portal).{0,250}(yes|true|enable|enabled)', t, re.S))
        if not portal_enabled:
            # Still keep a softer signal if portal section exists at all.
            portal_enabled = 'authentication-portal' in t or 'captive-portal' in t

    response_pages = 'response-page' in t or 'response pages' in t or 'response-pages' in t
    untrusted_hint = any(x in t for x in ['untrust', 'untrusted', 'internet', 'outside', 'wan'])

    if portal_enabled and response_pages and untrusted_hint:
        return 'exposed-likely'
    if portal_enabled:
        return 'enabled-unknown-reachability'
    return 'not-seen'


def main():
    args = parse_args()
    try:
        version, hostname = fetch_system_info(args.host, args.port, args.api_key, insecure=args.insecure)
        if not version:
            print('UNKNOWN - could not determine PAN-OS version')
            sys.exit(2)

        print(f'Host: {hostname}')
        print(f'PAN-OS version: {version}')

        if not is_version_in_scope(version):
            print('PATCHED - version branch not listed as affected for CVE-2026-0300')
            sys.exit(0)

        patched = is_version_patched(version)
        if patched is True:
            print('PATCHED - version is at or above a fixed release for its branch')
            sys.exit(0)

        # Vulnerable branch/build. Now try to infer whether the vulnerable portal path is configured.
        cfg = fetch_running_config(args.host, args.port, args.api_key, insecure=args.insecure)
        exposure = infer_portal_exposure(cfg)
        print(f'Exposure heuristic: {exposure}')

        if exposure == 'exposed-likely':
            print('VULNERABLE - affected version and portal appears enabled/reachable from untrusted context')
            sys.exit(1)
        elif exposure == 'enabled-unknown-reachability':
            print('UNKNOWN - affected version and portal appears enabled, but external reachability could not be proven from config export')
            sys.exit(2)
        elif exposure == 'not-seen':
            print('UNKNOWN - affected version, but Authentication Portal exposure was not detected in exported config')
            sys.exit(2)
        else:
            print('UNKNOWN - unable to classify exposure')
            sys.exit(2)

    except Exception as e:
        print(f'UNKNOWN - runtime error: {e}')
        sys.exit(3)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, build a list of every PA-Series and VM-Series firewall on affected branches, then split them into two buckets: Authentication Portal exposed to untrusted/public networks and everything else. Because this CVE is KEV-listed with active exploitation, override the normal HIGH timetable and patch / mitigate immediately, within hours for exposed systems by restricting the portal to trusted zones, disabling it if unused, and enabling Threat ID 510019 where supported; after that, move the remaining affected-but-not-exposed systems through the noisgate mitigation SLA exception path because there is no ordinary 30-day wait here for the exposed subset, and use the noisgate remediation SLA outer bound of ≤180 days only as a ceiling for residual low-exposure cases, not as permission to defer emergency cases past this week's change window.

Sources

  1. Palo Alto Networks advisory
  2. NVD record
  3. Palo Alto Unit 42 threat brief
  4. Rapid7 analysis
  5. Censys advisory
  6. CISA KEV catalog query
  7. Public GitHub exploit material
  8. Exposure note citing Shadowserver counts
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.