PAN-OS GlobalProtect CVE-2026-0257: A Forged Cookie Walks Past VPN Login, and the SMB June 1 Playbook

On May 29, 2026, CISA added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog and gave federal agencies until June 1 to fix or mitigate it. The flaw is an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS. An attacker who can reach your VPN can forge an authentication-override cookie and open a GlobalProtect session without a single valid credential. Palo Alto scored it CVSS 7.8. The number undersells it.

The timeline is the ugly part. Rapid7 traced the first in-the-wild exploitation to May 17, before most defenders had read the advisory. Two waves followed: one on May 18 at 01:51 UTC from Vultr-hosted infrastructure, and a second on May 21 that, in two observed cases, walked past authentication and was assigned an internal VPN IP address. That is the entire game in one sentence: a forged cookie in, a tunnel into the corporate network out.

If you run a 60-person company whose remote staff dial in through a Palo Alto firewall, this is your weekend, not a federal IT problem. GlobalProtect is a small-business remote-access standard precisely because Palo Alto sells it into MSPs and the mid-market. And the configuration that makes you vulnerable - one certificate reused for both the HTTPS portal and the authentication-override feature - is common, easy to set up by accident, and almost never reviewed once the firewall is racked. Here is what the bug actually is, how to tell in five minutes whether it can reach you, and what to hunt for in case it already did.

How a forged cookie becomes a VPN session

GlobalProtect has a convenience feature called authentication override. So users do not re-authenticate on every connect, the portal or gateway issues an encrypted cookie; present the cookie next time and you skip the login. The cookie is encrypted with a certificate you configure on the firewall. The whole design rests on one assumption: only the firewall can produce a cookie the firewall will accept.

It cannot. As Rapid7 documented, the gpsvc binary decrypts the cookie and then performs no signature verification of any kind. Integrity is never checked after decryption. Palo Alto classifies the weakness as reliance on cookies without validation and integrity checking, which is the polite way of saying the gate reads the badge but never confirms it issued it. The only thing standing between an attacker and a valid cookie is the encryption key - and that is exactly where the certificate reuse bites.

When an organization points the authentication-override feature at the same certificate already serving the GlobalProtect portal over HTTPS, the public key is not a secret. Anyone on the internet can pull it straight off the TLS handshake. With the public key in hand, an attacker forges a cookie that the firewall will happily decrypt, accept, and honor - logging in, in every observed case, as the local admin account. No password, no MFA prompt, no brute force. Just a request that looks like a returning user coming home.

Why this is worse than a 7.8 looks

The CVSS vector carries a low confidentiality impact because, in isolation, the bug "only" forges a session. In the field it is an unauthenticated foothold on the one device that sits at your perimeter and bridges to everything behind it. The accounts attackers went after were local administrators on the firewall itself. And in Rapid7's second wave, the forged session was handed a VPN IP, which places the attacker on the internal network as a trusted client - the exact position that ransomware crews pay initial-access brokers good money to obtain. A score that treats this like a minor information leak is reading the math, not the network.

Who is actually exposed

• You run a Palo Alto firewall (PA-Series or VM-Series) with a GlobalProtect portal or gateway configured.
• Authentication override cookies are enabled - the "Generate cookie for authentication override" and "Accept cookie for authentication override" options on the GlobalProtect agent configuration.
• The certificate used for the override feature is the same one serving the portal over HTTPS, or is otherwise reachable.
• Panorama and Cloud NGFW are not affected; this is a firewall data-plane issue, so do not let a clean Panorama lull you.

If the first three are true, treat yourself as exploitable and move today. If you are not certain whether override is on, assume it is. It is a convenience setting that people enable during rollout and never think about again.

Find out in five minutes, then patch

Start from the firewall CLI. Confirm the running version and whether the authentication-override cookie settings are present in your GlobalProtect config, then check from the outside whether the portal is even internet-facing:

# PAN-OS operational CLI
show system info | match sw-version

# Look for the authentication-override cookie settings in the running config
show config running | match "authentication-override"
show config running | match "cookie"

# From outside the network: is the GlobalProtect portal internet-facing at all?
curl -skI https://YOUR-VPN-HOST/global-protect/login.esp | head -n 1

Any version below the fixed train is in scope. The Palo Alto advisory lists the patched builds; map your branch and jump to the first fixed point release:

• 12.1: upgrade to 12.1.4-h6, 12.1.7, or later.
• 11.2: upgrade to 11.2.4-h17, 11.2.7-h14, 11.2.10-h7, 11.2.12, or later.
• 11.1: upgrade to 11.1.4-h33, 11.1.15, or later.
• 10.2: upgrade to 10.2.7-h34, 10.2.18-h6, or later.
• 9.0, 9.1, and 10.0 are end of life. There is no patch. Migrating to a supported branch is the fix, and it should have happened already.

If you cannot schedule a maintenance window before June 1, apply the vendor mitigation now and patch after. The advisory gives two options, and either one breaks the forged-cookie path immediately. Disable authentication override entirely, which costs your users a re-authentication and buys you a large risk reduction; or generate a brand-new certificate used only for the override feature, so its public key is never exposed through the HTTPS portal. Mitigate first, patch second, but do not let "we will patch next sprint" be the plan for an actively exploited edge device.

Hunt for the sessions you may already have

Exploitation predates the advisory by almost two weeks, so "we patched" is not the same as "we were not hit." Pull your GlobalProtect authentication logs back to at least May 16 and look for cookie-based logins to the admin account from sources your staff never use. Rapid7 published concrete indicators worth grepping for directly:

# On the firewall: GlobalProtect auth events for the local admin account
show log globalprotect direction equal backward | match admin

# Grep exported GlobalProtect/auth logs for the published attacker source IPs
grep -E '104\.207\.144\.154|146\.19\.216\.(119|120|125)' gp-auth.log

# Forged-client tells: spoofed machine names and a placeholder MAC
grep -E 'GP-CLIENT|DESKTOP-GP01|aa:bb:cc:dd:ee:ff' gp-auth.log

The source addresses (104.207.144.154 and the 146.19.216.0 cluster), the client machine names GP-CLIENT and DESKTOP-GP01, and the all-placeholder MAC aa:bb:cc:dd:ee:ff are the artifacts Rapid7 observed across multiple victims. Any one of them against your admin account is a confirmed intrusion, not a curiosity. And if you find a match, the firewall is the start of the investigation, not the end of it. A forged admin session can rewrite config, add accounts, export the very certificate that makes re-exploitation trivial, and pivot inward across everything the VPN pool can reach.

If you forward firewall logs to a SIEM, build a standing rule instead of a one-time grep. The signal is clean, because a GlobalProtect cookie authentication to a local administrator account from a never-before-seen IP is not something your remote workforce generates:

# Splunk: GlobalProtect cookie auth to a local admin from a new source
index=pan sourcetype="pan:globalprotect" auth_method=cookie user=admin
| stats count min(_time) AS first_seen values(src_ip) AS src_ips by user
| where count > 0

Rapid7 ships a managed detection for exactly this pattern under the name "Suspicious Authentication - Palo Alto GlobalProtect Cookie Authentication to Local Admin Account." If you are not their customer, the logic above reproduces it on any platform that ingests PAN-OS logs. The point is to make the forged-cookie login loud, because it is otherwise indistinguishable from a normal reconnect.

The move this weekend

Three steps, in order, and the clock is the CISA deadline of June 1. First, determine whether you run GlobalProtect with authentication override and a shared certificate; if you do, you are in scope, full stop. Second, mitigate now - disable override or issue a dedicated certificate - and schedule the upgrade to a fixed PAN-OS build. Third, hunt your authentication logs back to May 16 for the published indicators before you call this closed. A VPN that lets a stranger in wearing your administrator's badge is not a finding you sit on across a long weekend. Patch it, then go looking for whoever did not wait for you to.