This is the seventh piece in our attack-research series. The recurring thesis holds: the bugs that take down an enterprise are rarely exotic. They are published, patched-in-an-advisory, working-PoC-in-a-week vulnerabilities sitting on a device that should never have exposed its management surface to an untrusted network in the first place. PAN-OS this quarter is the canonical case. Verifiable security.
The cluster, in one table
Palo Alto's security advisory portal published a tight band of CVE identifiers this quarter. We are not going to recite every byte of every advisory; we are going to name the ones that matter for an external attacker walking the management plane, because those are the ones an internet-facing device hands over for free.
- CVE-2026-0300: PAN-OS captive-portal pre-auth RCE. The headline. Unauthenticated remote code execution against the captive-portal authentication endpoint. Unit 42's threat brief documents active exploitation by CL-STA-1132, who deploy EarthWorm and ReverseSocks5 tunnels post-exploit (published SHA-256
e11f69b4…f97a584). CWE-787 / CWE-78. This is the one with a wild-exploitation clock on it. - CVE-2026-0264: PAN-OS DNS-proxy heap overflow. Memory-corruption RCE in the DNS-proxy component reachable on the data/mgmt boundary. CWE-122. Patch baseline below
12.1.5 / 11.2.6 / 11.1.7 / 10.2.13is in range. - CVE-2026-0263 / -0258: PAN-OS IKEv2 packet RCE + Certificate-URL SSRF. An out-of-bounds write reachable from the IKEv2 SA-INIT exchange (CWE-787), paired with a Certificate-URL fetch that an attacker can point at a controlled endpoint (CWE-918 SSRF). The SSRF half is the cheap, safe-to-confirm signal; the RCE half is the impact.
- CVE-2026-0265: PAN-OS Cloud Authentication Service bypass. An authentication weakness in the CAS endpoint (CWE-287) that, under the right replay conditions, accepts a session it should reject.
- CVE-2026-0257: GlobalProtect auth-override bypass. An authentication-bypass on the GlobalProtect portal/gateway (CWE-287). The portal is the single most-exposed PAN management surface on the internet, which is what makes this the highest-leverage entry in the cluster after the zero-day.
- CVE-2026-0227: GlobalProtect denial of service. The low end of the cluster by impact (CWE-400), but it bookends the CVE band and is trivially reachable on the same exposed portal. We mention it because an attacker who can crash your VPN concentrator on demand has leverage even without code execution.
- CVE-2026-0244: Prisma SD-WAN ION certificate-validation bypass. A trust-boundary failure (CWE-295) on the SD-WAN management fabric, where the device completes a TLS handshake against an attacker-chained untrusted CA. Different product, same management-plane theme.
The band is wider than these seven, since the advisory range spans parser DoS, a WildFire WF-500 management-UI path-traversal (CVE-2026-0259), and others, but every entry that matters for an external attacker shares one property: it is reachable because a management or authentication surface is answering from an untrusted network. That is the re-audit.
Why this still ships in 2026
Palo Alto is not a careless vendor. PAN-OS is one of the most-scrutinised network operating systems on earth. So why does a fresh cluster of pre-auth management-plane CVEs land every quarter? Three structural reasons, none of them about Palo Alto specifically:
- The management plane is a web application, and web applications have bugs. The GlobalProtect portal, the captive portal, the CAS callback, the admin UI: these are HTTP services with parsers, session handling, cookie logic, and certificate-fetch code paths. Every one of those is attack surface. A firewall is, from the management plane's point of view, just another app server, and it inherits the entire app-server bug class: buffer overflows in request parsing (CVE-2026-0300, -0264), SSRF in outbound fetches (CVE-2026-0258), auth-override logic errors (CVE-2026-0257, -0265), and TLS-validation shortcuts (CVE-2026-0244).
- Exposure is the default, not the exception. A GlobalProtect gateway exists to be reached from the internet. That is its job. The captive portal exists to greet unauthenticated users. The line between "this surface is supposed to be public" and "this surface is supposed to be admin-only" is drawn in configuration, and configuration drifts. Internet-wide scan data consistently shows tens of thousands of PAN management interfaces, admin UIs, not just VPN gateways, answering on the open internet. The advisory says "restrict management interface access to trusted IPs." The deployment, three years and two acquisitions later, does not.
- The patch window is the exploit window. Every CVE in this cluster had a vendor advisory with affected-version ranges and a fixed-version target. CL-STA-1132 did not wait. Unit 42's brief on CVE-2026-0300 documents exploitation concurrent with disclosure. For pre-auth RCE on an internet-facing security appliance, the gap between "advisory published" and "mass scanning begins" is measured in hours, not weeks. The customers who got hit were running a version one or two maintenance releases behind the fix, on a box whose management plane was reachable.
The attacker decision tree
From an answering management interface to an internal foothold: the five-step tree an attacker walks against an exposed PAN edge.
The decisive observation is step 3: the attacker does not need to know in advance which path works. They fingerprint the version, line it up against the advisory band, and try the cheapest fitting variant first. An auth-override cookie POST (CVE-2026-0257) costs one request and either returns a portal-config redirect or it does not. A Certificate-URL SSRF probe (CVE-2026-0258) costs one IKEv2 exchange and either fires an out-of-band callback or it does not. Only when the cheap, safe-to-send probes confirm a vulnerable surface does an attacker who is actually willing to break the law reach for the in-the-wild RCE. The whole exercise is scriptable, and against an internet-wide PAN install base, it is run at scale by everyone from CL-STA-1132 down to commodity ransomware crews.
A composite real-world scenario
The setting is a mid-market logistics operator. They run a pair of PAN-OS firewalls at the perimeter, with GlobalProtect terminating remote-worker VPN and a captive portal for guest Wi-Fi at depot sites. The boxes were stood up by a managed-service partner in 2023, patched on the partner's quarterly cadence, and, this is the part that matters, the admin web UI was left reachable from a "management" subnet that, after a network re-architecture, quietly became routable from the internet through a misconfigured cloud transit gateway. Nobody re-audited the exposure after the re-architecture. The advisory's "restrict management access" guidance was followed in 2023 and silently undone in 2025.
An attacker running internet-wide PAN fingerprinting flags the GlobalProtect portal first. They pull the login page, read the build string, and line it up against the quarter's advisory band. The version is two maintenance releases behind the fix for CVE-2026-0257. They send a single crafted request to the portal with the auth-override cookie set, and the gateway responds the way a vulnerable build does: a redirect to getconfig.esp and a freshly minted PORTAL-Authentication cookie. They are now treated as an authenticated portal client.
# Step 1 — fingerprint the exposed GlobalProtect portal
$ curl -sk https://vpn.target.example/global-protect/login.esp \
| grep -oE 'pan_(login|portal)[^"]*' # build/version string
# Step 2 — probe the auth-override path (CVE-2026-0257 class)
$ curl -sk -i https://vpn.target.example/global-protect/getconfig.esp \
-H 'Cookie: PHPSESSID=A; GlobalProtectGW-Auth-Override=1' \
--data 'user=svc-monitor&portal=GP-Portal'
HTTP/1.1 200 OK
Location: /global-protect/getconfig.esp
Set-Cookie: PORTAL-Authentication=8b3f...; Path=/; Secure
With portal-client access established, the attacker pulls the gateway config that the portal hands back. On an unpatched, exposed PAN edge that config is a treasure chest: the IKE pre-shared keys for site-to-site tunnels, the LDAP/RADIUS bind credentials the firewall uses to authenticate VPN users against the directory, local admin hashes, and certificate material. The directory bind credential alone is the prize: it is a valid corporate account with read access to the entire user directory.
# Step 3 — from the config, two trophies that matter most
# (a) directory bind credential → internal recon as a real user
# (b) IKE pre-shared keys → spoof / decrypt site tunnels
ldapsearch -x -H ldaps://dc01.corp.target.example \
-D 'CN=svc-pan-bind,OU=Service,DC=corp,DC=target,DC=example' \
-w '<recovered-bind-password>' \
-b 'DC=corp,DC=target,DC=example' '(objectClass=user)' sAMAccountName
From there the pivot is mechanical. The directory bind credential drives internal reconnaissance: enumerate users, find privileged groups, locate the next hop. If the box were running an unpatched captive-portal build, the same actor would have an even shorter path: CVE-2026-0300 is pre-auth RCE, and Unit 42 documents CL-STA-1132 dropping EarthWorm and ReverseSocks5 reverse tunnels immediately on success, turning the firewall itself into the pivot point. Either way, the entry was not a zero-day discovered by a genius. It was an exposed management plane plus a published CVE plus a patch that was two releases late.
What we observe in customer environments
We are honest about the limits of our visibility. CelvexGroup's continuous validation runs against the assets a customer flags into scope; we are not auditing the internal management VLAN of every device. What we do probe, on every external engagement that includes perimeter network gear, is the management-plane exposure surface above. Across engagements this quarter, the rough pattern:
- Edge management surfaces drift into exposure more often than teams believe. The single most common finding is not an unpatched CVE. It is an admin UI or management API that the customer was certain was IP-restricted, answering from an address it should not. Re-architectures, cloud transit gateways, and "temporary" firewall rules that outlived their author are the usual cause.
- Version drift against the current advisory band is widespread. A meaningful share of internet-facing PAN portals we fingerprint are running a build that predates the fix for at least one CVE in the current quarter's cluster. The gap is almost never "they refuse to patch"; it is "the maintenance window slipped and nobody re-checked against the advisory feed."
- The cheap, safe probes are the ones that confirm. We do not fire RCE payloads at customer production. The auth-override-cookie response signature, the CAS replay behaviour, the IKEv2 Certificate-URL out-of-band callback, and the version-in-range banner are enough to assert exposure with confidence and zero risk to the device. The verdict path is multi-signal: banner-in-range and behavioural confirmation, never a single weak signal.
The honest read: the PAN management-plane cluster is a textbook case of a finding that is high-impact, externally confirmable without touching the dangerous payload, and almost entirely about exposure-plus-patch-latency rather than novel exploitation.
What to do about it: the re-audit
The fix is not a single patch. It is a re-audit of the management plane as a whole, because the cluster is a symptom and the exposed-and-stale management surface is the disease. We summarise it as a checklist every PAN edge should pass this month.
PAN management-plane re-audit: six controls that close the cluster
- Re-verify management-interface exposure from the outside, today. Do not trust the config that says "restricted to trusted IPs." Scan your own public ranges for the admin UI (
/php/login.php,/sslmgr), the GlobalProtect portal, and any captive-portal endpoint. If the admin plane answers from an untrusted address, that is the finding: close it before you patch anything. - Patch to or past the current fixed-version baseline for the whole cluster. CVE-2026-0300 (captive portal, in-the-wild), CVE-2026-0264 (DNS-proxy), CVE-2026-0263/-0258 (IKEv2), CVE-2026-0265 (CAS), CVE-2026-0257/-0227 (GlobalProtect). Pull the fixed-version targets from the Palo Alto security advisory portal and confirm your running build is at or past every one.
- Prioritise the captive-portal patch as an incident, not a maintenance item. CVE-2026-0300 has confirmed active exploitation. If your captive-portal build is in range and the surface is reachable, treat it as an emergency change, not a quarterly ticket.
- Rotate every secret the firewall config holds. If a management surface was exposed and in-range at any point this quarter, assume the config could have been read. Rotate IKE pre-shared keys, the LDAP/RADIUS bind credential, local admin passwords, and API keys. A patched box still holding a credential an attacker already pulled is not remediated.
- Add the PAN advisory feed to your CVE-monitoring with a seven-day SLA. Every CVE in this cluster had a vendor advisory with affected ranges. The customers who got hit were not unpatchable; they were un-monitored. Wire the advisory feed to your patch process so the next quarter's cluster is a same-week change.
- Re-run the exposure check on a schedule, not once. Exposure drifts. The re-architecture that re-exposed the admin plane will happen again. Continuous external validation of the management surface, not an annual pen test, is what catches the drift the day it happens.
Re-verify the exposure from the outside before you patch a single CVE. A patched firewall whose admin plane still answers from the internet is one advisory away from the next finding.
The exposure check, in concrete terms, is a handful of requests against your own public ranges: confirm the management UI and portal endpoints either do not answer or answer only from your administration network, and confirm every reachable build is at or past the fixed version for the cluster. It is finishable in an afternoon for a typical edge estate, and it is the single highest-leverage hour your network team will spend this quarter.
How Celvex catches this
Find. Prove. Fix. Verify.
The scanner fingerprints PAN-OS / GlobalProtect / Prisma SD-WAN management surfaces by banner and login-page signature, maps the build to the current advisory band, and probes the cheap, safe variants: auth-override response, CAS replay, IKEv2 Certificate-URL out-of-band callback.
For a confirmed exposure we ship a Proof Capsule with the exact request, the response signature that confirms the vulnerable build, and the multi-signal verdict, never an RCE payload against production, always reproducible evidence.
The Capsule's remediation block names the affected CVEs, the fixed-version target, the exposure to close first, and the secrets to rotate, scoped to the specific build and surface we fingerprinted.
After the patch and exposure-fix land, the probe returns the patched-build signature and the management surface stops answering from untrusted space. The finding closes automatically and the dashboard records the verified-fix event for the auditor record.
Where we sit on the autonomy curve: at L1.5 today, our scanner carries a tagged corpus for the PAN management-plane cluster: banner-and-version fingerprinting plus the safe behavioural probes for the GlobalProtect auth-override, CAS replay, and IKEv2 Certificate-URL SSRF paths, each gated behind a multi-signal AND so a legacy cookie or a stray banner never trips a false positive. At L2 within 90 days, the corpus extends to active version-drift tracking against the live advisory feed, so a newly-disclosed PAN CVE becomes a scanner check within the patch window rather than the quarter after. We do not send the captive-portal RCE payload, and we never will against production: passive version-in-range plus exposure confirmation is the verdict path for the in-the-wild bug. We claim that our L1.5 today catches the exposed-and-stale management plane reliably and ships a reproducible Capsule for it.
Bottom line
The PAN-OS cluster this quarter, CVE-2026-0227 through CVE-2026-0265, plus the in-the-wild CVE-2026-0300, is not a story about a uniquely vulnerable vendor. It is a story about the management plane: the GlobalProtect portal, the captive portal, the admin UI, the cloud-auth callback, all of which are web applications, all of which inherit the web-application bug class, and any of which becomes a foothold the moment it answers from an untrusted network while running a build that is two releases behind the advisory. The fix is a re-audit, not a single patch: confirm the exposure from the outside, patch the whole cluster to baseline, prioritise the captive-portal bug as an incident, rotate the secrets the config held, and wire the advisory feed to a seven-day SLA. Until that re-audit, every exposed PAN edge in your estate is one published CVE away from handing an attacker your config, your credentials, and a tunnel into your network.
Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.
Sources
- Palo Alto Networks: Security Advisories portal (CVE-2026-0227…0265 cluster, fixed-version baselines)
- Unit 42: Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated RCE (CVE-2026-0300, CL-STA-1132)
- Palo Alto Networks: CVE-2026-0300 advisory (PAN-OS captive-portal pre-auth RCE)
- Palo Alto Networks: CVE-2026-0257 advisory (GlobalProtect auth bypass)
- Palo Alto Networks: CVE-2026-0264 advisory (PAN-OS DNS-proxy heap overflow)
- Palo Alto Networks: CVE-2026-0263 / -0258 advisory (PAN-OS IKEv2 RCE + Certificate-URL SSRF)
- Palo Alto Networks: CVE-2026-0265 advisory (PAN-OS Cloud Authentication Service bypass)
- Palo Alto Networks: CVE-2026-0244 advisory (Prisma SD-WAN ION certificate-validation bypass)
- CELVEX Group: Proof Capsule format
Re-audit your own edge.
Free Exposure Check, no signup required. We fingerprint your public-facing PAN management surfaces against the current advisory cluster and ship a Proof Capsule for the highest-confidence finding.
Run a Free Scan →