CVE-2026-0257: GlobalProtect authentication bypass via forged override cookies

What it is

GlobalProtect can issue an authentication override cookie after a user logs in, so the client can reconnect without asking for credentials (and MFA) again. On vulnerable versions, the portal and gateway decrypt that cookie and trust its contents without checking a signature.

The cookie is encrypted with a certificate’s public key. If that certificate is also used somewhere an outsider can read it, typically the portal or gateway’s own HTTPS certificate, anyone can build a valid-looking cookie for any user and open a VPN session. No password and no MFA.

That’s why the original medium rating was misleading. On a firewall with the risky configuration, this is a direct path into the internal network, and ransomware operators have used it exactly that way.

Am I affected?

You’re exposed only if all three are true:

1. Your PAN-OS version is in the affected range (see the table above).
2. A GlobalProtect portal or gateway has authentication override cookies enabled. This is off by default but widely used to cut down repeated MFA prompts.
3. The certificate that encrypts the cookies is also used elsewhere, such as the portal or gateway’s SSL/TLS service profile.

Check your version (CLI):

show system info | match sw-version

Check whether override cookies are on. In the web interface:

• Portal: Network > GlobalProtect > Portals > your portal > Agent > your agent configuration > Authentication. Look at Generate cookie for authentication override and Accept cookie for authentication override.
• Gateway: Network > GlobalProtect > Gateways > your gateway > Agent > Client Settings > your profile > Authentication Override. Look at Accept cookie for authentication override.

Or from the CLI, list every override setting in one go:

set cli config-output-format set
configure
show | match authentication-override

Check the certificate. In the same authentication override settings, note the certificate used to encrypt and decrypt the cookie. If it’s the same certificate your portal or gateway presents over HTTPS, or one used by any other feature, treat the device as exploitable.

Prisma Access tenants on the affected versions are covered by the same advisory. Panorama and Cloud NGFW are not affected.

What to do

1. Upgrade. Move to a fixed hotfix on your branch. Pick the newest one available, not just the minimum listed here: later Palo Alto advisories, such as CVE-2026-0310 in September, need newer builds than this fix.

2. Upgrade every portal and gateway that issues or accepts cookies together. Palo Alto warns that mixing fixed and unfixed devices breaks cookie compatibility. For phased rollouts, the advisory FAQ describes a temporary setting (enable-auth-override-cookie-hmac no) that relaxes the new check on upgraded devices. Set it back to yes as soon as everything is upgraded, because the fix isn’t enforced until then.

3. Warn your helpdesk. After the upgrade, the firewall regenerates cookies with the new method, so every GlobalProtect user must log in again once, even with a valid cookie. Expect a wave of MFA prompts and tickets.

If you can’t upgrade tonight, use one of the vendor workarounds:

• Dedicated certificate: generate a new certificate used only for authentication override cookies. Don’t reuse the portal or gateway certificate, and don’t reuse any certificate that was ever used by another service. This keeps the feature working and closes the attack path.
• Disable authentication override: uncheck the generate and accept options on portals and gateways. This is the bluntest fix, but users will authenticate (and get MFA prompts) on every connection.

After patching: terminate active GlobalProtect sessions so any forged sessions are cut off, then hunt for past compromise (below). If you find a successful forged login, treat it as a network intrusion, not a VPN issue.

Detection

Exploitation leaves traces in the GlobalProtect logs (Monitor > Logs > GlobalProtect). Search back to at least May 17, 2026:

• Successful logins where the authentication method is Cookie, especially for local accounts such as admin. Rapid7 saw forged cookies used against the local admin account across several customers.
• A cookie decryption error followed by a successful login in the same session (Arctic Wolf).
• Successful logins from VPS hosting providers (such as Vultr), Tor exit nodes, or countries your users aren’t in.
• Client host names kali, GP-CLIENT, DESKTOP-GP01, WINDOWS-LAPTOP-001 or Jocker, and placeholder MAC addresses aa:bb:cc:dd:ee:ff or 00:11:22:33:44:55.
• The public proof of concept’s fixed values: endpoint OS “Microsoft Windows 10 Pro 64-bit” with an empty domain field (Unit 42).
• In web or WAF logs: POSTs to /ssl-vpn/login.esp carrying portal-userauthcookie or portal-prelogonuserauthcookie, followed by /ssl-vpn/getconfig.esp and /ssl-vpn/hipreport.esp (Rapid7).

After VPN access, the observed activity was fast and noisy:

• SMB and NTLM authentication from VPN-assigned addresses to many hosts within minutes, including NTLM anonymous logons and Impacket-style reconnaissance.
• LSASS memory dumps and NTDS.dit extraction, then lateral movement with PsExec.
• In Qilin cases: the ransomware binary staged as C:\PerfLogs\win.exe, AnyDesk, ngrok, rclone and the scheduled task \MeshUserTask.