osbytes

Search

Find posts, projects, and members.

← back to blog

GlobalProtect cookie forgery lands on CISA KEV as Palo Alto confirms attacks

2026-05-29by@osbytes6 min read
#security #cve #cisa-kev #pan-os #vpn #coordinated-disclosure

TL;DR

  • CISA's KEV JSON feed (catalogVersion 2026.05.29, released 2026-05-29T19:00:06Z) lists CVE-2026-0257 with dateAdded 2026-05-29 and dueDate 2026-06-01.
  • Palo Alto's advisory moved to Exploit Maturity: ATTACKED today and notes limited exploit attempts on unpatched, unmitigated firewalls.
  • Rapid7's exploitation write-up (published today) walks the cookie-forgery chain and publishes IOCs plus a public forge_cookie.py checker.

Why today matters

The technical story for CVE-2026-0257 has been public since May 13: a GlobalProtect authentication override cookie can let a remote attacker skip normal login when the feature is on and the cookie encryption certificate is reused with another TLS surface. That is not new.

What changed today is operator pressure and confirmation. CISA's catalog row turns "we should patch soon" into a three-day federal clock for agencies under BOD 22-01. Palo Alto's timeline line "Updated exploitation status" on 2026-05-29 matches what Rapid7's MDR team says it has been seeing in customer environments since at least May 17: successful Cookie logins that should not have happened.

If you run GlobalProtect with auth-override cookies enabled, treat this as an edge VPN incident, not a routine medium CVSS item sitting in the queue.

How the bypass actually works

Authentication override is optional. When enabled, the portal or gateway can hand users a long-lived cookie so they do not re-enter credentials every session. Under the hood, GlobalProtect encrypts that cookie with an RSA key tied to a certificate you configure.

The bug is not "cookies are bad." It is no integrity check after decryption. Rapid7's reverse engineering of gpsvc on a vulnerable PAN-OS 10.2.8 lab box shows main_DecryptAppAuthCookie base64-decoding the incoming value, decrypting with the configured private key, and then trusting the plaintext fields (username, domain, host id, client OS, remote address, timestamp) without a signature step. Anyone who can encrypt with the matching public key can mint a cookie the appliance accepts.

The vendor advisory's configuration footnote is the other half of the puzzle: you are exposed when the same certificate used for cookie crypto is also exposed elsewhere, so an unauthenticated attacker can learn the public key from a normal TLS handshake to the portal or gateway. Rapid7's PoC script (forge_cookie.py) iterates every certificate in the HTTPS chain, forges a cookie with each public key, and posts to /ssl-vpn/login.esp until one is accepted. In their lab screenshot, the second chain cert (a lab CA), not the leaf, was the one that worked.

Routing still uses the real HTTP path; only the reconstructed URL used for cookie auth is wrong. That is why the failure mode is "VPN front door opens" rather than a subtle app bug.

What Rapid7 saw in the wild

Rapid7 says exploitation showed up across numerous MDR customers, with the earliest observed activity on May 17, 2026. Two waves stood out:

  • May 17–18: cookie auth to the local admin account from 104.207.144.154 (Vultr), client string GP-CLIENT, Linux user agent.
  • May 21: similar cookie auth from 146.19.216.125 (Dromatics Systems), hostname DESKTOP-GP01, Windows 10 Pro user agent.

Both waves reused the same spoofed client MAC aa:bb:cc:dd:ee:ff in GlobalProtect logs. Rapid7 did not see confirmed lateral movement after VPN establishment, but they also note that in 8 of 10 impacted customers the appliance accepted the forged cookie without assigning a full VPN session. Do not treat "no tunnel IP" in your logs as proof you were skipped.

Tech-support review on affected boxes commonly showed Cloud Authentication Service disabled and authentication override cookies enabled, which matches the advisory's required configuration.

What to do on your fleet

Work from Palo Alto's matrix, not a blog paraphrase. Fixed builds include, among others, PAN-OS 10.2.7-h34+, 11.1.4-h33+, 11.2.4-h17+, 12.1.4-h6+, and the listed Prisma Access maintenance releases on the advisory page. After upgrade, expect a one-time re-auth for users who relied on override cookies; the vendor regenerates cookies with a safer method.

If you cannot patch before the weekend, the vendor mitigations are blunt but effective:

  1. Turn off "Generate cookie" / "Accept cookie" for authentication override on both portal and gateway objects.
  2. Or issue a dedicated certificate used only for override cookies and nowhere else (no sharing with the HTTPS listener chain).

Confirm exposure in the UI paths Palo Alto documents under Required Configuration for Exposure (portal Agent → Authentication tab; gateway Client Settings → Authentication Override tab).

Hunt using Rapid7's IOC list: source IPs 104.207.144.154, 146.19.216.119, 146.19.216.120, 146.19.216.125; hostnames GP-CLIENT and DESKTOP-GP01; cookie-auth success lines with the spoofed MAC above. Rapid7 also ships authenticated exposure checks in InsightVM/Exposure Command since the May 15 content release.

Reading the severity labels

Palo Alto rates the issue HIGH with HIGHEST suggested urgency and CVSS-BT 7.8. Rapid7 argues the edge-VPN context warrants treating it like a critical edge breach even when the numeric score looks "medium." The actionable point is simpler: unauthenticated network attackers, no user click, and a feature many enterprises turned on for convenience.

Panorama and Cloud NGFW are out of scope for this CVE; the blast radius is firewalls running GlobalProtect portal/gateway with the vulnerable cookie setup.

Sources