The full Tailwind Analysis on this naming gotcha is in TRG-SA-2026-003, "Captive Portal's legacy footprint."

Requirements

• Python 3.10 or newer
• Standard library only — no pip install required
• A PAN-OS API key with read access to the firewall (or, for Tier 2, to Panorama)
• A CA-signed (or operator-trusted) certificate on the firewall management interface; --insecure is provided for one-shot bring-up audits only

Tier 1 — single firewall

Example table output:

Other output formats: --output json or --output csv.

Other flags: --vsys <name> for single-vsys audit, --timeout/--retries for slow upstreams, --debug for verbose error details on stderr.

Tier 2 — Panorama fleet sweep

Each row in the CSV is one device-vsys with portal status, redirect host, mode, interface bindings, and a risk classification. The script uses Panorama's target=<serial> API parameter so it never connects to managed firewalls directly — one connection to Panorama sweeps the whole fleet.

Notable flags:

• --workers N — concurrent audit threads (default 8, max 32). A 1000-device fleet completes in minutes rather than the hour-plus a serial sweep would take.
• --timeout, --retries — per-API-call settings. Transient URLError and HTTP 5xx are retried with bounded backoff.
• --exclude-disconnected — by default, disconnected devices are included with risk=DISCONNECTED so they remain visible during the patch window. Use this flag to drop them.
• --min-expected-devices N — warn (stderr) if Panorama returns fewer devices than N. Useful to detect response truncation against a known fleet size.
• --serial-filter '0007*' — glob-filter by serial to audit a subset.
• --debug — print verbose per-device error details to stderr (includes upstream reason strings; off by default to avoid leaking hostnames into customer-facing CSVs).

Risk classification

The risk column in output is one of:

EXPOSED_LIKELY is a hint, not a verdict — zone names are operator conventions, not enforcement. The script cannot replace a security-policy walk; it sorts a fleet output to where attention should land first.

What the scripts do — and do not do

Do:

• Query <captive-portal> blocks per vsys (the schema element name is always captive-portal, regardless of UI naming or PAN-OS version).
• Report enabled/disabled, redirect host, mode, and zone-resolved interface bindings.
• Classify risk by zone-name heuristic so EXPOSED_LIKELY rows surface first in fleet output.
• Send the API key via the X-PAN-KEY header so it stays out of URL access logs and process arguments.
• Cap response body size (50 MB) to defend against entity-expansion attacks on the XML parser.
• Retry transient errors with bounded backoff.

Do not:

• Walk security policy comprehensively. Whether the portal is reachable from an untrusted network depends on policy rules, NAT, and zone bindings — the operator must complete that walk from the audit output.
• Test reachability by network probe. Pure config audit only.
• Modify any configuration. All API calls are read-only.

Generating a PAN-OS API key

The PAN-OS API key inherits the role and permissions of the user who generates it.

Important caveat: there is no read-only XML API grant in PAN-OS.

Admin Role permissions on the XML API tab are binary Enable/Disable per category — Configuration, Operational Requests, Commit, Export, Import, Report, Log, User-ID Agent. Enabling Configuration for XML API permits both show and set/edit/delete/move/rename/clone actions. Enabling Operational Requests permits arbitrary <request> operations including <request><restart>. The Web UI and REST API tabs offer Read-Only as an option; the XML API tab does not.

An "audit user" created by enabling these XML API categories holds full XML API write authority on the device. Treat the resulting key as a privileged credential: scope its lifetime to the audit window, store it in a secrets manager, and disable the user when the work is complete.

Canonical PAN reference: Get Your API Key (PAN-OS XML API).

Through the WebUI

On the firewall (or Panorama, if you're using audit_fleet.py):

1. Create the Admin Role. Navigate to Device > Admin Roles (or Panorama > Admin Roles). Click Add.

   • Name the role e.g. audit-config-and-op.
   • On the Web UI tab, set everything to None (no UI access needed for the audit user).
   • On the XML API tab, enable Configuration and Operational Requests. Leave Commit, Export, Import, Report, Log, and User-ID Agent disabled.
   • Click OK. The resulting role grants full XML API Configuration and Operational Requests authority — see the caveat above.

2. Create the audit user. Navigate to Device > Administrators (or Panorama > Administrators). Click Add.

   • Name: e.g. audit-cve-2026-0300.
   • Set a strong password or bind to an Authentication Profile.
   • Administrator Type: Role Based → select audit-config-and-op.
   • Click OK, then Commit the candidate config.

3. Generate the API key with the new user's credentials. PAN-OS does not expose a "generate API key" button in the WebUI — the keygen endpoint is the supported path. Use a POST body so credentials are not logged in URL access logs:

   root@kitploit:~

   read -rs AUDIT_PW; echo
   export PAN_API_KEY="$(curl -ksX POST "https://fw1.example.com/api/" \
     --data-urlencode "type=keygen" \
     --data-urlencode "user=audit-cve-2026-0300" \
     --data-urlencode "password=$AUDIT_PW" \
     | grep -oE '<key>[^<]+' | cut -c6-)"
   unset AUDIT_PW
   

   read -rs reads the password without echoing it to the terminal and without putting it in shell history. The script reads the resulting PAN_API_KEY from the environment and sends it via the X-PAN-KEY HTTP header — neither the password nor the key appears in URL access logs or in ps auxww while the script runs.

4. Disable the user when the audit work is complete. Navigate to Device > Administrators, locate audit-cve-2026-0300, click Delete (or disable the user). Commit. This invalidates any keys generated for that user.

Hardening notes

• Keep the password and key out of shell history. read -rs covers the password. For the key in PAN_API_KEY, prefer setting it interactively via the snippet above rather than pasting from a file. If you must source it from a file, use set +o history for the session.
• Use a CA-signed certificate on the firewall management interface. The --insecure flag in both audit scripts disables TLS hostname check and certificate validation entirely. Any attacker on path can MITM the audit response and report portal_enabled=False for a rooted device. The audit_fleet.py script requires --accept-mitm-risk alongside --insecure for fleet sweeps because the blast radius of a poisoned response is fleet-wide.
• Rotate the key when complete. Disabling or deleting the audit user invalidates all keys generated under that user.

Exit codes

• 0 — no portal enabled on any audited vsys
• 2 — no vsys found (transient or unsupported configuration)
• 3 — portal enabled on at least one vsys (review required)
• 4 — API call failed (auth, TLS, network)

The non-zero exit on "portal enabled" is intentional — it lets you wire the script into CI / fleet-sweep pipelines that need a clean signal.

License

Licensed under the Apache License, Version 2.0. See LICENSE for the full terms.

Commercial use is permitted; attribution is required (retain the copyright notice and license file in derivative works).

Copyright 2026 Tailwind Resource Group.

See also

• TRG-SA-2026-003 — Tailwind Resource Group security advisory for CVE-2026-0300
• PAN PSIRT — https://security.paloaltonetworks.com/CVE-2026-0300
• PAN best-practice (restrict portal access) — https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000CqbiCAC
• Tailwind Resource Group — https://tailwindrg.com