Detecting CVE-2026-0265 at Scale: PAN-OS CAS Authentication Bypass

TL;DR: CVE-2026-0265 is a pre-authentication JSON Web Token (JWT) signature bypass in PAN-OS and Panorama, reachable only when Cloud Authentication Service (CAS) is attached to an authentication profile. Bishop Fox has published a detection script that returns a definitive vulnerable / not-vulnerable verdict per GlobalProtect portal from a single anonymous HTTP request. Patch to a fixed version (10.2.18+, 11.1.15+, 11.2.12+, 12.1.7+) or detach CAS from affected profiles as a workaround.

Summary

CVE-2026-0265 lets an unauthenticated, remote attacker forge a JWT and log in as any user the firewall trusts. Two interfaces are affected: attacks against the GlobalProtect portal can compromise virtual private network (VPN) user sessions, while attacks against the management interface can compromise the PAN-OS administrator account. In both cases, PAN-OS must be configured with CAS attached to an authentication profile. Without that precondition, the vulnerable code path is never invoked.

Palo Alto Networks rated the bug 7.2 (high severity) for the case where the management interface is internet-exposed and gave the GlobalProtect portal a separate, lower Common Vulnerability Scoring System (CVSS) score. Harsh Jaiswal of HacktronAI, the original reporter, publicly disputed that rating on the basis that he had bypassed CAS-protected GlobalProtect portals on multiple production tenants and has since published his own technical analysis.

Our independent analysis of the patched binaries confirms his root-cause findings, but for this article we will focus on defense. We built a detection tool that pulls two important data points (the CAS precondition and the PAN-OS version) out of the same anonymous prelogin response and determines if the target is vulnerable to CVE-2026-0265.

Our detection script is available at https://github.com/BishopFox/CVE-2026-0265-check.

What Defenders Should Do Right Now

Remediation advice from the vendor is straightforward:

• Patch. Upgrade to the fixed version for your branch (10.2.18+, 11.1.15+, 11.2.12+, 12.1.7+). Several hotfixes shipped on May 13; the rest are expected May 28.
• If you can't patch, detach CAS. Replace CAS with SAML, RADIUS, LDAP, or local auth on every authentication profile attached to a GlobalProtect portal or admin role. This neutralizes the bug on that profile.
• Enable Threat ID 510008 if you have a Threat Prevention subscription and you're on PAN-OS 11.2 or later. The signature requires several routing prerequisites; the advisory's Workarounds section lists them.
• Audit your management interface exposure. The PAN-OS management interface shouldn't be internet-reachable in the first place. That's a security risk regardless of whether the CAS precondition is met.
• Sweep your fleet with our detection script. Hits marked vulnerable are your patch list. Cloud-managed (SaaS) assets shouldn't be affected, and undetermined results require administrator review.

The Bug in One Paragraph

Palo Alto Networks classified this vulnerability as CWE-347, improper verification of a cryptographic signature. The root cause is JWT algorithm confusion in pan_auth_verify (in libpanmp_mp.so), which dispatches signature verification on the alg value parsed from the attacker-controllable JWT header. The vulnerable build happily accepts alg=HS256 and computes a hash-based message authentication code (HMAC) over whatever bytes the caller staged as the verification key. Crucially, it does so even when those bytes are a PEM-encoded RSA public key that the firewall fetched from CAS to verify RS256-signed tokens. Anyone who can read that public key, which Palo Alto's regional CAS service exposes to enrolled devices, can pre-compute the matching HMAC and forge a token for any user.

This is a textbook JWT algorithm confusion bug, and the canonical fix (refuse to HMAC if the key bytes look like a PEM-encoded asymmetric key) is exactly what the patch implements.

Two Surfaces, One URL

A key detail is that both vulnerable interfaces (GlobalProtect and management) answer at the same external path: /SAML20/SP/ACS. Which listener is on the other end depends on which Nginx server block handles the request.

The administrator case is the more severe one: write firewall config, drop into a command-line interface (CLI) shell from the web management terminal panel, read RADIUS shared keys and stored private keys, pivot to Panorama. Jaiswal's GlobalProtect portal claim is the more publicly visible side of this bug, but it is the less severe side.

Both surfaces share the same vulnerable function (pan_auth_verify) and the same gating condition: CAS must be attached to the authentication profile in front of the listener.

One scope note before moving on: the detection technique we describe in the rest of this post fingerprints the GlobalProtect portal surface only. The management interface doesn't expose the unauthenticated endpoint we read from, so a clean external assessment against that surface needs a different approach. In practice, the more important point is that the management interface shouldn't be reachable from the internet in the first place. If yours is, that exposure is itself the priority finding and should be closed before chasing the CVE-specific triage.

A Two-Factor Verdict From a Single Request

For a GlobalProtect portal to be exploitable, two independent things have to be true:

1. CAS attached: the targeted listener's authentication profile uses CAS.
2. Affected version: the firewall is on a PAN-OS build below the per-base patched-hotfix cutoff in the vendor advisory.

If either factor is false on its own, the target isn't exploitable. The cleanest external assessment is one that observes both factors, on the same host, in one pass. PAN-OS's own unauthenticated prelogin endpoint hands us exactly that, and it hands us the firewall's authoritative self-reported version while it's at it, which beats every banner-scraping or TLS-cert heuristic we've tried.

The probe is a single anonymous GET /global-protect/prelogin.esp. No authentication, no body modification, no state change. The only caveat is that this endpoint can be configured to require an mTLS client certificate, which not only interferes with detection but also mitigates exploitation by unauthorized attackers.

Factor 1: CAS attachment

The prelogin response is a small XML document that the GlobalProtect agent normally consumes before submitting credentials. Among its fields:

<cas-auth>yes</cas-auth>

The firewall emits <cas-auth>yes</cas-auth> exactly when CAS is the configured authentication method on the portal's login profile. The no and empty-value forms cover SAML, RADIUS, LDAP, and local-auth. Absence of the tag means an upstream gate blocked the probe: a client-certificate (mTLS) requirement, a GP-client version gate, or the host not being a GlobalProtect portal at all.

There's no guessing here: the portal is telling us its own auth configuration directly. We require the explicit yes form for a positive precondition verdict.

Factor 2: Authoritative PAN-OS version from an embedded JWT

The same prelogin response also carries a <saml-request> field whose contents are a base64-encoded auto-submit HTML form: the redirect handoff a real GlobalProtect client would forward to Palo Alto's CAS service to begin the authentication flow. Inside that form is a JWT issued by the firewall itself, and inside that JWT's payload is a claim populated from the appliance's own configuration:

"PanOSversion": "11.1.6-h32"

That claim is the authoritative version string. It comes from the same code path that determines what hotfix the appliance is running, so it cannot drift from what the firewall is actually executing the way a TLS certificate or HTML banner can. Recovering it is a straightforward three-step decode, with no cryptography involved:

1. Base64-decode the contents of the <saml-request> XML element to get the auto-submit HTML form.
2. Pull the JWT out of the form's hidden input (<input name="Token" value="HEADER.PAYLOAD.SIGNATURE">).
3. Base64url-decode the JWT's middle segment to get a JSON claim set. PanOSversion lives there.

The JWT's signature is never verified; we're reading a claim from a structurally valid token that the firewall hands out to anyone who asks. The token would be useful for an attacker only if forged with the right key (the bug we're discussing), but as a defensive read of the firewall's posture it's a gift.

Resolving the verdict against the advisory

With a recovered PanOSversion, the verdict is a table lookup against the vendor advisory's patch matrix. For each affected <train>.<base> release, the advisory publishes the lowest hotfix number that contains the fix. For example:

• 11.1.6-h32 → base 11.1.6's patch is h32. h32 ≥ h32 → not vulnerable.
• 11.1.6-h23 → same base, same patch. h23 < h32 → vulnerable.
• 11.2.7-h9 → base 11.2.7's patch is h13. h9 < h13 → vulnerable.
• 11.1.15 → the entire base is patched. → not vulnerable.

Bases that have no hotfix listed in their train (for example, 11.1.8 in the 11.1 train) are vulnerable across all hotfixes; the customer has to move up to a base release that does contain the fix.

The SaaS short-circuit

Cloud-managed PAN-OS builds emit a PanOSversion claim with a trailing .saas suffix (for example, 11.2.7-h9.saas). Per Palo Alto Networks' May 21, 2026 clarification, all SaaS builds are not affected by CVE-2026-0265: they're patched independently through the cloud-managed deployment pipeline. We short-circuit any .saas suffix straight to a not-affected verdict without consulting the on-prem hotfix matrix.

What Else The Prelogin Response Reveals

Decoding the embedded JWT also surfaces a handful of fields that aren't part of the verdict but are worth knowing exist, because the same probe that drives the patch decision will incidentally hand them to anyone scanning for them:

• SN claim: the appliance's serial number (also visible in the JWT header's x5c device certificate subject).
• TID claim: the firewall's tenant identifier, equivalent to the CSP-ID parameter that prior public disclosures noted is required for the forge-side claim set.
• Callback URL: the assertion-consumer URL the firewall expects CAS to redirect to.
• Regional CAS endpoint: the specific cloud-auth-service.<region>.apps.paloaltonetworks.com host this firewall's CAS pipeline is bound to.

For defenders, this is useful posture data: knowing what your portal hands out anonymously is part of the audit. For the broader research community, it's a reminder that "the precondition for this CVE" and "the parameters an attacker would need to weaponize the bug" overlap more than the original advisory framing suggests. We're not publishing a forge recipe in this post, but anyone reading both this analysis and HacktronAI's together can connect the dots, which is part of why patch urgency matters.

When The Assessment Abstains

The two-factor verdict only fires when both factors can be observed cleanly. Our detection tool explicitly does not assert a verdict when:

• The probe is upstream-gated. Targets requiring an mTLS client certificate, or that aggressively version-gate the GP-client User-Agent, return an error response without the CAS scaffolding. A separate precondition fingerprint can flag them as "CAS attached, manual triage," but the build can't be extracted from that response and a verdict has to wait on a different source.
• CAS isn't attached. SAML, RADIUS, LDAP, and local-auth profiles all yield the same not-vulnerable verdict regardless of build, because the bug's code path is not reachable.
• The host isn't a GlobalProtect portal. Services without PAN-OS content are out of scope by definition.

We also don't try to verify the bug by submitting a forged JWT. Every signal we use is something the firewall already publishes to anonymous visitors, which keeps the assessment safe to run at scale.

Conclusion

Credit to Harsh Jaiswal and HacktronAI for the original public discussion of remote exploitability against GlobalProtect portals. Our analysis confirms theirs and adds the defender-side detection technique, the on-prem-vs-cloud-managed split via the .saas suffix, and the embedded-JWT version-extraction primitive. The vendor advisory is the authoritative reference for affected versions and fixed hotfixes: security.paloaltonetworks.com/CVE-2026-0265.

Our Cosmos customers were notified about our research into this vulnerability shortly after the vendor advisory. If you're interested in learning more about managed services delivered through our Cosmos platform, visit https://bishopfox.com/services/continuous-threat-exposure-management.

For more vulnerability intelligence insights, visit the Bishop Fox Blog.