CVE-2026-0257: When a VPN Cookie Becomes a Free Login

Published: June 11, 2026 | Category: Palo Alto / Security Advisories | Author: Bhardwaj Vishnu | Affects: PAN-OS GlobalProtect (Portal & Gateway) | CVSS v4 Score: 7.8 (High) | CISA KEV: Added May 29, 2026

If you’re running a Palo Alto Networks firewall with GlobalProtect and you haven’t patched yet, stop reading this sentence and go check your PAN-OS version right now. CVE-2026-0257 is no longer a theoretical risk — it is being actively used in real attacks against real corporate networks, confirmed by both Rapid7 and Palo Alto’s own Unit 42 threat research team.

This isn’t a “patch it next maintenance window” situation. This is a “patch it this week or disable the vulnerable feature today” situation.

Here’s everything you need to know — what the flaw is, how attackers are exploiting it, how to tell if you’re vulnerable, and exactly what to do to fix it.

What Is CVE-2026-0257?

CVE-2026-0257 is an authentication bypass vulnerability in the GlobalProtect portal and gateway components of Palo Alto Networks PAN-OS software. It also affects Prisma Access deployments under specific configurations.

The vulnerability exists because PAN-OS doesn’t properly validate authentication override cookies. When GlobalProtect is configured to use these cookies, the firewall accepts them at face value — without checking whether they were actually issued by a legitimate authenticated user. An attacker who understands the cookie structure can forge one and present it to your GlobalProtect gateway, which then happily establishes a VPN connection as if it were a real user.

In plain terms: an unauthenticated attacker on the internet can connect to your internal network through GlobalProtect without ever providing valid credentials.

That’s a significant problem for any organisation running GlobalProtect as its primary remote access VPN — which is most enterprises using Palo Alto firewalls.

CVSS Score — Why the Number Kept Changing

You may have seen conflicting severity ratings for this CVE. Here’s what happened:

• May 13, 2026 (initial disclosure): Palo Alto assigned a CVSSv4 score of 4.7 (Medium)
• May 29, 2026 (update): Score revised upward to 7.8 (High) after active exploitation was confirmed
• NVD CVSS v3.1 base score: 9.1 (Critical)

Rapid7’s security researchers were blunt in their assessment: regardless of what the official score says, an authentication bypass on an edge-facing enterprise VPN appliance should be treated as critical priority. When attackers are already actively using a vulnerability, theoretical severity scores become less relevant than real-world impact.

What Does “Authentication Override Cookie” Actually Mean?

This is the bit that trips up most engineers when they first read the advisory. Let me explain it clearly.

GlobalProtect has a feature called authentication override cookies. When enabled, this lets users re-authenticate to GlobalProtect without going through the full MFA/SAML/LDAP process every time. The gateway issues a cookie after the first successful authentication, and subsequent connections use that cookie instead of full credentials.

It’s a convenience feature, and many organisations enable it specifically to reduce authentication friction for remote workers.

The problem is in how PAN-OS validates these cookies on inbound connections. Before the patch, the validation logic was insufficient — it checked that a cookie existed in the right format, but did not perform rigorous integrity checking to confirm the cookie was legitimately issued by that gateway for a real user. Attackers discovered they could forge cookies that passed this weak validation check and gain VPN access.

For this vulnerability to be exploitable, both of these conditions must be true:

1. GlobalProtect portal or gateway has “Generate cookie for authentication override” or “Accept cookie for authentication override” enabled
2. The same certificate is being used for authentication override cookie encryption/decryption as is used for another feature on the same device

If only one condition is met, you are not vulnerable. Both must be present.

How Attackers Are Actually Exploiting It

This is where it gets interesting, and where Rapid7’s incident response data gives us real detail that the vendor advisory doesn’t.

Rapid7’s Managed Detection and Response (MDR) team identified the first wave of exploitation on May 17, 2026 — just four days after Palo Alto published the advisory. A second wave followed on May 21st.

Here’s what the attacker behaviour looked like from the logs:

May 18 01:51:37 palovpn-01
GLOBALPROTECT, gateway-auth, login, Cookie,
admin, US, GP-CLIENT, 104.207.144.154,
MAC: aa:bb:cc:dd:ee:ff
Auth latency: 78ms, profile: local_auth_profile
Result: success

A few things stand out in that log line that should raise immediate red flags:

• Authentication method: Cookie — not LDAP, SAML, RADIUS, or certificate. Just a cookie.
• Username: admin — the attacker is targeting the local admin account, not a domain user.
• Auth latency: 78ms — suspiciously fast for a legitimate authentication flow.
• MAC address: aa:bb:cc:dd:ee:ff — this is a spoofed placeholder MAC, not a real device identifier.

After the cookie authentication succeeded, Rapid7 observed POST requests to:

• /ssl-vpn/hipreport.esp — submits fake endpoint security profile information
• /ssl-vpn/getconfig.esp — establishes the actual secure VPN tunnel

Once those two requests completed successfully, the attacker had a live VPN tunnel into the internal network with an IP address assigned from the VPN pool.

Both waves of exploitation originated from different hosting providers (Vultr in the first wave, Dromatics Systems in the second), but used the same spoofed MAC address — which is why Rapid7 concluded both waves were likely the same threat actor or the same toolkit being reused.

Across multiple impacted customers, Rapid7 observed that Cloud Authentication Service (CAS) was disabled on all affected appliances. This appears to be a prerequisite for the exploitation path to work.

The good news: as of the time of this writing, no confirmed post-exploitation lateral movement has been identified. Attackers established VPN sessions but have not been observed moving through internal networks in the disclosed incidents. However, Unit 42 emphasised this could change as the vulnerability becomes more widely understood.

Am I Vulnerable? How to Check

Step 1 — Check if GlobalProtect authentication override cookies are enabled

Log into your Palo Alto firewall GUI and navigate to:

For the GlobalProtect Gateway:

Network → GlobalProtect → Gateways → [your gateway] → Agent → Authentication

Look for these two checkboxes:

• “Generate cookie for authentication override”
• “Accept cookie for authentication override”

If both are unchecked, you are not vulnerable via the gateway. Repeat this check for your GlobalProtect Portal:

For the GlobalProtect Portal:

Network → GlobalProtect → Portals → [your portal] → Agent → [config] → Authentication

Step 2 — Check for certificate reuse

The second condition requires that the certificate used for authentication override cookie encryption is also used elsewhere on the device. Check which certificate is selected under the authentication override settings and verify whether that same certificate is used for other purposes (SSL/TLS decryption, management interface, or another VPN profile).

Step 3 — Check if Cloud Authentication Service is disabled

Device → Setup → Management → Cloud Services

If CAS is disabled AND your cookies are enabled with a shared certificate, treat yourself as vulnerable until patched.

Step 4 — Check your PAN-OS version

From the CLI:

> show system info | match sw-version

Compare against the fixed versions in the table below.

Affected and Fixed Versions

Note: Always verify against the official Palo Alto security advisory at security.paloaltonetworks.com/CVE-2026-0257 as this table may be updated by the vendor.

How to Fix It — In Order of Priority

Option 1 — Patch to a fixed PAN-OS version (permanent fix)

This is the definitive solution. Upgrade to the fixed version for your current PAN-OS branch. Standard upgrade path via the GUI:

Device → Software → Check Now → download and install the fixed version

Or via CLI:

> request system software check
> request system software download version 11.2.6
> request system software install version 11.2.6

Verify the running version after upgrade:

> show system info | match sw-version

If you’re running PAN-OS HA (Active/Passive or Active/Active), upgrade the passive unit first, perform a manual failover, then upgrade the original primary. This minimises downtime.

Option 2 — Disable authentication override cookies (immediate mitigation, no patch required)

If you cannot patch immediately, disable the authentication override feature entirely:

Gateway:

Network → GlobalProtect → Gateways → [gateway] → Agent → Authentication
→ Uncheck "Generate cookie for authentication override"
→ Uncheck "Accept cookie for authentication override"
→ Commit

Portal:

Network → GlobalProtect → Portals → [portal] → Agent → [agent config] → Authentication
→ Uncheck both override cookie options
→ Commit

Impact: Users will need to re-authenticate fully every time they connect. For organisations using MFA this means users go through the full MFA flow on each connection. Operationally disruptive but safe.

Option 3 — Generate a dedicated certificate for authentication override (mitigation, preserves cookie functionality)

If you need to keep the cookie feature enabled for operational reasons, you can break the vulnerability condition by creating a new, separate certificate exclusively for authentication override — one that is not shared with any other feature:

Device → Certificate Management → Certificates → Generate
→ Create a new self-signed certificate specifically for GlobalProtect auth override
→ Name it clearly: "GP-Auth-Override-Cert"
→ Apply it to the override cookie settings on portal and gateway
→ Commit

This removes the shared certificate condition required for exploitation, while preserving the cookie-based re-authentication for users.

Indicators of Compromise (IOCs)

Based on the published Rapid7 and Unit 42 reports, look for these indicators in your GlobalProtect logs:

Suspicious log patterns:

• Authentication method Cookie to a local account (especially admin) from an external IP
• MAC address aa:bb:cc:dd:ee:ff or other obviously spoofed all-hex placeholder MACs
• Successful GlobalProtect authentication from Vultr or Dromatics Systems IP ranges with no associated endpoint registration
• POST requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp from unauthenticated or newly authenticated sessions with no prior portal login

CLI command to review recent GlobalProtect authentications:

> show log globalprotect direction equal backward

Filter specifically for cookie-based logins:

> show log globalprotect direction equal backward type equal gateway-auth authmethod equal cookie

Look for any success results from external IPs using cookie authentication to local accounts. Any result here that you don’t recognise as a legitimate re-authentication from a known user should be investigated immediately.

Why This Matters Beyond the Patch

CVE-2026-0257 is a good reminder of something that comes up repeatedly in network security: VPN gateways are high-value targets precisely because legitimate access through them is trusted access.

Once an attacker establishes a VPN session, their traffic enters your network from an internal IP address within the VPN pool. Depending on how your security zones are configured, this may bypass firewall policies that you’ve carefully built to protect internal resources from untrusted sources. A VPN-connected IP is, by definition, in a trusted zone — because you built it that way for your legitimate remote workers.

This is why vulnerability response on edge-facing VPN appliances needs to be faster than on internal systems. The blast radius when VPN authentication is bypassed is potentially the entire internal network.

A few broader lessons worth applying:

Review your certificate reuse. The second condition for this vulnerability — a shared certificate — is something that often happens organically as organisations expand their Palo Alto deployments. The same certificate gets applied to multiple features for simplicity. Audit your certificate inventory and make sure critical features use dedicated certificates.

Re-examine who can authenticate to what via GlobalProtect. If your GlobalProtect gateway allows local account authentication (especially the built-in admin account) from the internet, that’s a broader risk regardless of this CVE. Consider restricting GlobalProtect authentication to domain accounts via LDAP/SAML, disabling local account VPN access at the gateway level, and enabling split tunnelling so VPN-connected users still pass security inspection.

Treat CISA KEV additions as immediate action items. When CISA adds a CVE to the Known Exploited Vulnerabilities catalog, that’s not a recommendation — for federal agencies it’s a compliance requirement, and for everyone else it’s a strong signal that real-world exploitation is confirmed at meaningful scale. CVE-2026-0257 was added on May 29 with a June 1 remediation deadline for FCEB agencies. That timeline reflects genuine urgency.

Summary — Quick Reference

References

• Palo Alto Networks Security Advisory: security.paloaltonetworks.com/CVE-2026-0257
• Unit 42 Threat Brief: unit42.paloaltonetworks.com/active-exploitation-of-pan-os-cve-2026-0257
• Rapid7 ETR: rapid7.com/blog/post/etr-rapid7-observed-exploitation-of-pan-os-globalprotect-authentication-bypass-vulnerability-cve-2026-0257
• CISA KEV Catalog: cisa.gov/known-exploited-vulnerabilities-catalog

Read Also: Fortinet FortiASIC Architecture Deep Dive: NP7, CP9, and SP5 Processors

Last verified: June 11, 2026 | Applies to PAN-OS versions prior to the fixed releases listed above