A critical security flaw in Palo Alto Networks firewalls is now under active attack. Hackers are using forged authentication cookies to bypass security controls and access VPN sessions they never had permission to enter.
The vulnerability, tracked as CVE-2026-0257, affects GlobalProtect, Palo Alto’s remote access VPN solution built into PAN-OS. Palo Alto disclosed it on May 13. Attackers moved against it within days.
Forged cookies unlock VPN access across multiple victims
Security firm Rapid7 caught the attacks early. According to Rapid7, attackers sent forged authentication cookies to firewalls across several customer environments, and the appliances accepted those cookies without establishing a full VPN session in 8 out of 10 affected Managed Detection and Response (MDR) customers. That is a high success rate for what amounts to a credential forgery operation.
The company has not observed any confirmed lateral movement from the compromised devices. Attackers gained entry but have not yet pushed deeper into the networks.
CVE-2026-0257 exploits a gap in how Palo Alto firewalls handle cookie-based authentication. The firewalls accept cookies without running thorough validation or integrity checks on them. That gap lets remote, unauthenticated attackers bypass security restrictions and establish unauthorized VPN connections.
According to Palo Alto Networks, the issue specifically targets firewalls running the GlobalProtect portal or gateway with authentication override cookies enabled, alongside a particular certificate configuration. The vulnerability covers both physical and virtual firewalls running PAN-OS, as well as Prisma Access, the cloud-delivered version of Palo Alto’s firewall capabilities.
How the attack actually works
The authentication override feature started as a convenience tool. It issues cookies to already-verified users so they do not have to re-enter credentials on every new connection. Under the wrong certificate setup, that convenience becomes an open door.
Rapid7 broke down the mechanics. When the certificate handling authentication override cookies is the same certificate powering the portal’s HTTPS service, attackers can pull the public key simply by connecting to that HTTPS service.
That key gives them what they need to craft a valid authentication override cookie. The server then decrypts the cookie and trusts its content without running any signature verification.
No second check. No alert. The firewall accepts the connection.
Rapid7 recorded two separate attack waves: the first on May 17, 2026, and the second on May 21. Both waves carried a consistent spoofed MAC address. According to Rapid7, the shared detail points strongly toward a single threat actor running both operations.
Rapid7 has since published indicators of compromise alongside a proof-of-concept script that security teams can use to test whether their appliances are still exposed.
CISA steps in as the deadline hits
The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog. The agency ordered all US federal civilian agencies to remediate the flaw by June 1, 2026, making today the enforcement deadline.
Certificate-related breaches are under increasing scrutiny. DigiCert’s breach and the theft of code-signing certificates highlight how certificate infrastructure vulnerabilities can have widespread consequences.
Palo Alto customers who have not upgraded to a patched version need to act now. Three remediation paths exist. The first is upgrading to the fixed PAN-OS version immediately.
The second is disabling the authentication override feature entirely. The third is generating a new, dedicated certificate for authentication override use only, completely separate from the certificate serving the HTTPS portal.
Each option cuts off the specific attack path hackers are currently using. Leaving systems unpatched, especially after confirmed exploitation at scale, is a risk no organization should accept.
The speed of this situation deserves attention on its own. Palo Alto disclosed the vulnerability on May 13. Attackers launched their first wave just four days later. That gap between disclosure and active exploitation keeps shrinking. Security teams can no longer afford to treat patch cycles as routine maintenance.
