This is the most urgent security item of the week. On May 13, 2026, Palo Alto Networks published an advisory for CVE-2026-0257: a remote, unauthenticated attacker can forge "authentication override" cookies and establish unauthorized VPN connections through the GlobalProtect gateway. Worse, this is not theoretical — it is being actively exploited, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on May 29.
1. The Technical Root Cause
Technically, the problem lives in a non-default feature called "authentication override": it issues authenticated users a session cookie similar to a bearer token so they don't have to re-authenticate each session. The trigger condition is the crucial part — the attacker can only forge a valid cookie when the certificate used to encrypt and decrypt that cookie is shared with another feature, such as the HTTPS service of the portal or gateway. In other words, this is a configuration-and-key-isolation design trap, not a simple code bug.
2. The Exploitation Timeline
Rapid7 MDR sharpened the timeline: the earliest exploitation traces to May 17, with the first wave originating from IPs hosted on Vultr; on May 18 it detected suspicious cookie-based authentication against local admin accounts; a second wave hit on May 21, where some victims were even assigned full VPN IPs after cookie authentication — handing attackers a direct ticket into internal networks. Mitigation is twofold: disable the authentication override feature, or generate a dedicated certificate used exclusively for that feature and shared with nothing else.
My Take
For those of us who build websites and systems, the lesson here goes far beyond "go patch Palo Alto." It demonstrates a pattern that keeps repeating: a convenience feature designed for user experience (no repeated logins), once combined with a seemingly harmless config shortcut like sharing a key, becomes a way to bypass the entire authentication system. Map it onto the Laravel/Nginx environments we touch every day and the lesson is identical: signing keys for JWTs or sessions must never be shared across services or environments; one certificate should not serve both public TLS and API-token signing; APP_KEY and various signing secrets must be strictly isolated, rotated regularly, and kept different between staging and production. I'd treat this as a free red-team reminder: go audit your own systems for places where one key opens many doors. The tension between convenience and security never goes away — but key and certificate isolation is one of the few lines that should never be crossed for the sake of saving effort.
Sources
- CVE-2026-0257 PAN-OS: GlobalProtect Authentication Bypass — Palo Alto Networks Security Advisory
- Rapid7 Observed Exploitation of PAN-OS GlobalProtect Auth Bypass (CVE-2026-0257) — Rapid7
- PAN-OS GlobalProtect Authentication Bypass Under Active Exploitation — The Hacker News
- Hackers are exploiting Palo Alto GlobalProtect VPN auth bypass (CVE-2026-0257) — Help Net Security
- Palo Alto GlobalProtect VPN auth bypass flaw now exploited in attacks — BleepingComputer