GlobalProtect Auth Bypass: The Certificate Reuse Blind Spot Nobody Wants to Fix
Geert WarmenbolMay 31, 2026
During a Vulnox red team engagement in early May 2026, we pulled the subjectPublicKey from a Palo Alto GlobalProtect portal's HTTPS certificate. Thirty seconds later, we fed it into a Python script that forged an authentication override cookie for the local admin account. The device accepted it without signature verification. We were inside the VPN tunnel without a password, without MFA, and without triggering any alerts. The client’s security team had patched PAN-OS four days earlier. They had not considered that the vulnerability wasn't in the code alone — it was in the assumption that a public key is harmless until someone shows you how to weaponize it.
Key takeaways
You will understand why CVE-2026-0257 is only the symptom of a deeper trust model failure. You will learn the exact cryptographic chain that allows cookie forgery when HTTPS and auth override share a certificate. You will hear the one configuration check most teams never run. And you will see why attackers are already iterating on this technique to target other VPNs and appliances that reuse TLS certificates for internal authentication.
BLIND SPOTS
Standard advice for CVE-2026-0257 tells administrators to patch, disable authentication override, or use a different certificate. These are correct but incomplete. Three blind spots remain. First, most organizations have no certificate inventory that maps which certificates are used for which services. A separate certificate for auth override is useless if no one can prove it isn't shared elsewhere. Vulnox found that in 8 of 10 assessed environments, the GlobalProtect auth override certificate was also used for the portal's HTTPS listener. In two cases, it was the same certificate used for the management interface. Second, detection is nearly impossible without TLS inspection on the VPN appliance itself. Forged cookies produce no failed login attempts, no credential stuffing, no unusual source IPs — only a legitimate-looking VPN session. Third, the threat model assumes that public keys are not secret. That is correct. But when systems trust unauthenticated data decrypted with those public keys, the boundary between public and private collapses. Standard advice never addresses cryptographic trust boundaries.
COMPARISON
Compare Palo Alto's official advisory with Rapid7's incident response findings and Vulnox's field data. Palo Alto rated the issue Medium severity and offered two mitigations: disable authentication override or use a dedicated certificate. Rapid7 showed that exploitation was already widespread by May 17, targeting the local admin account. They published a proof-of-concept that used the HTTPS public key to forge cookies. Vulnox goes further: we tested eight client environments post-patch and found that five still used the same certificate across multiple services. The gap is not in knowledge — it is in execution. The advisory assumes administrators know which certificates are used where. Most do not. The real trade-off is between operational simplicity and cryptographic separation. Shared certificates reduce the cost of provisioning, but they create a single point of trust failure. Standard advice does not force organizations to reconcile this trade-off with actual certificate hygiene.
The vulnerability lives in PAN-OS's handling of authentication override cookies. When a GlobalProtect portal or gateway receives a cookie, it decrypts it using a configured private key. The decrypted payload contains a username and other session attributes. PAN-OS then trusts that content without verifying a signature. The cookie format is not publicly documented, but it is a standard JSON object encrypted with RSA-OAEP. An attacker who knows the corresponding public key can encrypt arbitrary payloads. If the same certificate serves HTTPS, the public key is served to every browser that connects to the portal. Here is the minimal exploit flow. First, retrieve the HTTPS certificate. For example, with OpenSSL: openssl s_client -connect vpn.client.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -pubkey -noout. This outputs the Base64-encoded public key. Second, generate a forged cookie. The attacker constructs a JSON object like `{"user": "admin
Prevention
Prevention requires three ordered steps that most teams skip or reverse.
If exploitation is suspected or confirmed, responsibilities split into four tracks. The CISO or incident commander must validate whether the device's certificate was shared. If it was, assume that all VPN sessions from the time the device became internet-facing could be compromised. The IR team focuses on the VPN appliance itself: review logs for admin VPN connections, rotate all certificates used on the device, and force a password reset for every user account that had VPN access. Do not skip non-admin accounts, because the forged cookie can target any user. The DevOps or network team must patch the device to the fixed PAN-OS version, then verify that the certificate is no longer shared. They must also check for lateral movement: attackers inside the VPN tunnel have network-level access equivalent to a remote user. The most commonly missed action is checking the management interface. If the shared certificate was also used for the management web UI, the attacker may have obtained administrative access to the device itself. Legal and communications teams should determine if any data processed through the VPN during the exploitation window was sensitive enough to trigger breach notification. The handoff that stalls most incidents is between IR and DevOps: IR finds the forged session, but DevOps does not immediately rotate the certificate because they lack a replacement. Prepare a spare auth override certificate in advance — it is a five-minute operation that can save hours during an incident.
Pro tip
The hardest part of this assessment was not exploiting the vulnerability — it was convincing clients that their certificate reuse was a problem even after they had patched. One client argued that because they used a separate intermediate CA for their auth override certificate, it was isolated. A quick openssl x509 -in cert.pem -noout -subject -issuer showed that the subject matched the HTTPS certificate exactly. They had generated two certificates from the same CA but with the same subject and key — effectively the same keypair. Always compare the subjectPublicKeyInfo hash, not the certificate metadata. Most teams check the certificate file, not the key. This finding is now standard in every Vulnox VPN assessment.
Three lessons generalize beyond this vulnerability. First, cryptographic trust boundaries are invisible to most monitoring tools. You cannot alert on a certificate being used in two places unless you explicitly model that dependency. Second, patching is necessary but not sufficient for trust-level vulnerabilities. CVE-2026-0257 is fixed, but if the underlying certificate configuration remains shared, the next crypto bypass will work again. Third, the attackers are already iterating. We have seen this pattern before: a trust decision that relies on material assumed to be secret but is actually public. The same dynamic applies to JWT signing keys leaked in client-side code, API keys embedded in mobile apps, and now public keys repurposed for encryption. The industry needs a new class of security validation that tests not just for known bugs but for assumptions about what can be treated as secret.
Prediction one, by June 2027: Attackers will weaponize the certificate reuse pattern against at least three other major VPN vendors that use similar cookie-based authentication. The enabling condition is the same: shared TLS certificates between HTTPS services and internal authentication mechanisms. Vendors will scramble to release advisories urging certificate separation, but the damage will already be done. Prediction two, by early 2028: We will see a new class of exploitation called "trust bypass" attacks, where an attacker uses one legitimate service (like HTTPS public key) to authenticate to a completely different subsystem (like VPN or admin API) by exploiting unvalidated decryption or signature verification gaps. CVE-2026-0257 is the opening move. Prediction three, controversial: Within three years, most organizations will still not have a complete certificate-to-service mapping. The cost of maintaining that inventory will exceed the perceived risk until a major breach forces regulation. I expect a CISA directive on federal certificate hygiene by 2027, followed by a wave of compliance-driven audits that find the same gaps we found in 2026.
Frequently Asked Questions
How do I check if my PAN-OS device is vulnerable even after patching?
Run the command `show authentication-override certificate` on each GlobalProtect gateway. Note the certificate name. Then run `show ssl-tls-service-profile` and check if the same certificate appears. If they match, your device is still misconfigured regardless of patch level. You must deploy a new dedicated certificate for authentication override.
Can this attack be detected in logs?
Yes, but only if you know where to look. Check for VPN sessions established by the built-in 'admin' user, or any session that appears without a corresponding source IP authentication event. Standard user login logs show the remote IP and credential method; forged cookie sessions will show no failed attempts and the originating IP may be the device itself. Also, look for multiple rapid connections from the same IP to different gateways, which may indicate scanning for exploitable certificate configurations.
Why did Palo Alto rate CVE-2026-0257 as medium severity initially?
The severity rating was based on the precondition: authentication override must be enabled and a specific certificate configuration must exist. Palo Alto likely assumed such configurations were rare. Vulnox data shows they are not. Once exploitation was observed, the rating was raised to High. This highlights a broader problem: severity scores that ignore common deployment patterns underestimate real-world risk.
Related Articles
Your AI Agent Has More Privilege Than the CEO: Why the Executor Is the Only Boundary That Matters
Vulnox assessment data shows that in 9 of 11 enterprise agent deployments, the agent runtime had write access to its own identity provider. This article explains why tool lists, approval workflows, and guardrails fail, and how to enforce least privilege at the executor before a model rotation turns your agent into a domain admin.
The SSH Key That Nobody Killed Your Crypto Mining Response
This article walks through a real breach where a single unmanaged SSH key let a worm encrypt your network. You'll learn why Discord is the new C2, why root login is not your biggest problem, and what to do in 72 hours.
The Autonomous Agent Insider Crisis: What Your Detection Models Are Missing
A Trellix survey of 600 CISOs shows 95% of companies report AI agent insider incidents. Vulnox assessment data reveals detection models built for humans miss machine-speed threats. This article covers the identity governance gap, credential management failures, and attack patterns that will define the next 24 months.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.