If your organization uses Palo Alto Networks firewalls to provide remote access via GlobalProtect, this vulnerability needs your attention today. CVE-2026-0257 is an authentication bypass in PAN-OS's GlobalProtect portal and gateway that allows a remote unauthenticated attacker to establish a full VPN connection; no credentials required. Active exploitation was confirmed within four days of disclosure, a second wave of attacks followed shortly after, and CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on May 29, 2026.
The initial CVSS score assigned to this vulnerability was 4.7, placing it in the medium severity band. That number does not reflect the operational reality. Palo Alto Networks updated its advisory on May 29 to raise the score to 7.8 High, and Rapid7, whose managed detection team observed exploitation across multiple customer environments, characterized it as critical. An authentication bypass on an edge-facing VPN gateway is not a medium-severity event regardless of what the formula says.
What is CVE-2026-0257?
CVE-2026-0257 is an authentication bypass in Palo Alto Networks PAN-OS, specifically in the GlobalProtect portal and gateway components. It was discovered internally by Palo Alto Networks' own security research teams and published on May 13, 2026.
The vulnerability is not universally present in every PAN-OS deployment. It requires two configuration conditions to be met simultaneously:
- Authentication override cookies must be enabled on either the GlobalProtect portal or gateway.
- The certificate used to encrypt and decrypt those authentication override cookies must be shared with another feature — most commonly, the HTTPS service of the portal or gateway itself.
If both conditions are present, an unauthenticated attacker can forge a valid authentication override cookie and use it to establish a VPN connection.
What are authentication override cookies?
GlobalProtect's authentication override feature is a convenience mechanism. When enabled, a successfully authenticated user receives an encrypted cookie from the portal or gateway. On subsequent connections, the client presents this cookie in lieu of re-entering credentials - functionally similar to a session bearer token.
The cookie is encrypted using a certificate. In a correctly configured deployment, this certificate is dedicated solely to the authentication override feature, kept private, and not exposed to external parties.
How the bypass works
Rapid7's research into the vulnerability, confirmed by a working proof-of-concept, explains the flaw clearly. When GlobalProtect receives a POST request to /ssl-vpn/login.esp with a portal-userauthcookie or portal-prelogonuserauthcookie form parameter, the server decrypts the cookie and trusts its contents. The problem is what happens, or rather doesn't happen, after decryption: there is no signature verification. The server decrypts the cookie and immediately treats the extracted username, domain, and other fields as authoritative.
For this to be exploitable, an attacker needs to know the public key of the certificate used for cookie encryption. If the operator has reused the portal or gateway's HTTPS service certificate for the authentication override feature, that public key is freely available: any client connecting to the HTTPS endpoint can retrieve it from the TLS handshake.
The attack sequence is therefore: retrieve the certificate chain from the HTTPS endpoint, iterate through each certificate to try its public key, forge and encrypt an authentication override cookie, submit it to the gateway, and receive an authenticated VPN session.
Rapid7 Labs published a proof-of-concept script, forge_cookie.py, that automates exactly this process. Its output on a vulnerable appliance makes the mechanics visible:
[*] Retrieving certificate chain from 192.168.86.99:443 ...
Found 2 certificate(s) in chain:
[0] CN=192.168.86.99 (RSA 2048 bits, CA=False)
[1] CN=GP-Lab-CA (RSA 2048 bits, CA=True)
[*] Forging cookie for user 'haxor', testing each key
Trying [0] CN=192.168.86.99
[-] Failure - Gateway did not accepted the forged cookie
Trying [1] CN=GP-Lab-CA
[+] Success - Gateway accepted the forged cookie
No prior access. No credentials. No exotic tooling.
Active exploitation: what happened
Exploitation moved quickly after the May 13 advisory, and the pattern observed by Rapid7 MDR is worth understanding in some detail.
First wave: May 17–18. Rapid7 detected authentication events against multiple customer GlobalProtect gateways originating from a Vultr-hosted IP address. The authentication method recorded in PAN-OS logs was Cookie, and the account accessed was the local admin account. The machine name presented in authentication logs was GP-CLIENT, consistent with a Linux client. Rapid7 concluded this was exploitation of CVE-2026-0257, which was subsequently confirmed by a successful proof-of-concept replication in the lab.
Second wave: May 21. A second cluster of exploitation events was observed originating from addresses associated with the hosting provider Dromatics Systems. The machine name presented in this wave was DESKTOP-GP01, consistent with a Windows client. Rapid7 assesses both waves as likely the same threat actor, given the consistent use of the spoofed MAC address aa:bb:cc:dd:ee:ff across all events.
In the second wave, VPN IP assignment was observed following successful cookie authentication in some cases, meaning the attacker received internal network access in those instances. Rapid7 observed POST requests to /ssl-vpn/hipreport.esp (submitting security profile information) and /ssl-vpn/getconfig.esp (establishing the secure tunnel) in cases where a full VPN session was established. Across the customer environments affected, a VPN session was fully established in 2 out of 10 impacted cases; the remaining 8 showed the forged cookie being accepted without a full tunnel being built.
Rapid7 did not observe lateral movement from the compromised VPN sessions in any of the affected environments. That is relevant context, but it does not reduce the urgency: an attacker with authenticated VPN access to an enterprise network has everything they need to begin reconnaissance, and in a different engagement they may simply not have been observed doing so.
CISA added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog on May 29, 2026.
Who is affected?
The vulnerability affects PAN-OS across several recent release trains, as well as Prisma Access. The following table summarises affected and fixed versions:
| Product | Affected | Fixed In |
|---|---|---|
| PAN-OS 12.1 | < 12.1.4-h6 / < 12.1.7 | ≥ 12.1.4-h6 / ≥ 12.1.7 |
| PAN-OS 11.2 | < 11.2.4-h17 / < 11.2.7-h14 / < 11.2.10-h7 / < 11.2.12 | ≥ 11.2.4-h17 / ≥ 11.2.7-h14 / ≥ 11.2.10-h7 / ≥ 11.2.12 |
| PAN-OS 11.1 | < 11.1.4-h33 / < 11.1.6-h32 / < 11.1.7-h6 / < 11.1.10-h25 / < 11.1.13-h5 / < 11.1.15 | ≥ 11.1.4-h33 / ≥ 11.1.6-h32 / ≥ 11.1.7-h6 / ≥ 11.1.10-h25 / ≥ 11.1.13-h5 / ≥ 11.1.15 |
| PAN-OS 10.2 | < 10.2.7-h34 / < 10.2.10-h36 / < 10.2.13-h21 / < 10.2.16-h7 / < 10.2.18-h6 | ≥ 10.2.7-h34 / ≥ 10.2.10-h36 / ≥ 10.2.13-h21 / ≥ 10.2.16-h7 / ≥ 10.2.18-h6 |
| Prisma Access 11.2 | < 11.2.7-h13 | ≥ 11.2.7-h13 |
| Prisma Access 10.2 | < 10.2.10-h36 | ≥ 10.2.10-h36 |
Panorama and Cloud NGFW are not affected.
Prisma Access deployments are being actively upgraded by Palo Alto Networks as part of a scheduled upgrade rollout; customers should confirm their upgrade status with Palo Alto Networks support.
Critically, the vulnerability is not present in every deployment running an affected version. Both configuration conditions described above - authentication override cookies enabled, and a shared certificate - must be present. However, shared certificates are a common misconfiguration. Many operators configure GlobalProtect using the same certificate across multiple features for simplicity, without awareness of the security implications. Do not assume you are safe because the configuration seems unlikely; verify it explicitly.
What should you do?
1. Check whether your configuration is vulnerable
Before anything else, determine whether your GlobalProtect configuration meets both trigger conditions.
Check authentication override cookies on the Portal:
- Navigate to Network → GlobalProtect → Portals in the management interface.
- Click your Portal Name → Agent tab → your Agent Configuration profile.
- Go to the Authentication tab.
- Look for Generate cookie for authentication override or Accept cookie for authentication override. If either is checked, authentication override is active.
Check authentication override on the Gateway:
- Navigate to Network → GlobalProtect → Gateways in the management interface.
- Click your Gateway Name → Agent tab → your Client Settings profile.
- Go to the Authentication Override tab.
- Check whether Accept cookie for authentication override is enabled.
If authentication override is disabled on both portal and gateway, you are not affected by this vulnerability and no further action is required beyond applying the patch at your next available window.
If it is enabled, proceed immediately to steps 2 and 3.
2. Apply the immediate mitigation
If patching is not immediately possible, Palo Alto Networks recommends either of the following mitigations:
Option A: Disable authentication override entirely. Uncheck the authentication override options in both the portal and gateway configuration. This eliminates the attack surface completely. Users will need to re-authenticate on every VPN connection rather than using a cached cookie.
Option B: Dedicate a new certificate to authentication override. Generate a new certificate exclusively for authentication override cookies. This certificate must not be the same as the certificate used for the HTTPS service of the portal or gateway, and must not be shared with any other feature. Store it securely. This removes the attacker's ability to retrieve the public key from the TLS handshake.
To confirm you have eliminated the shared-certificate condition: the certificate used for authentication override must not appear in the certificate chain presented by the GlobalProtect HTTPS endpoint.
3. Patch
Apply the fixed PAN-OS version for your release train. Consult the Palo Alto Networks advisory for the precise hotfix version that applies to your minor version.
After upgrading, note that PAN-OS will regenerate authentication override cookies using a more secure method. All GlobalProtect users will be required to re-authenticate once after the upgrade, even if a valid cookie is currently cached. This is a one-time event; cookie-based authentication will function normally again after that initial re-authentication.
4. Review your logs for exploitation indicators
Whether or not you have applied the mitigation or patch, review your GlobalProtect authentication logs for signs of prior exploitation. Look for:
- Authentication events with method
Cookiefor accounts that should not be logging in that way, especially local admin accounts. - Machine names
GP-CLIENTorDESKTOP-GP01in authentication events not associated with known enrolled devices. - The MAC address
aa:bb:cc:dd:ee:ffin GlobalProtect authentication logs. - Authentication events originating from the following threat actor IPs identified by Rapid7:
104.207.144.154,146.19.216.119,146.19.216.120,146.19.216.125,209.99.191.137,79.130.26.202. - POST requests to
/ssl-vpn/hipreport.espor/ssl-vpn/getconfig.espfrom unexpected sources, particularly in proximity to a cookie authentication event.
Repeated cookie authentication events from the same external source, particularly against administrator accounts, are a strong exploitation indicator and warrant immediate investigation.
Detection
PAN-OS logs the authentication method used for each GlobalProtect connection in the GlobalProtect system logs. A forged-cookie authentication will appear with method Cookie and will not be accompanied by the usual credential-based authentication events that would precede a legitimate cookie issuance.
Key detection patterns:
Forged cookie authentication to admin or service accounts:
gateway-auth | login | Cookie | admin
Legitimate admin logins via GlobalProtect are rare. Cookie authentication for admin accounts from unexpected external IPs should always generate an alert.
Spoofed MAC address:
aa:bb:cc:dd:ee:ff
This placeholder MAC was consistently used by the threat actor observed by Rapid7 and is not a value a legitimate client would present.
VPN tunnel establishment following anomalous cookie authentication:
Filter for /ssl-vpn/getconfig.esp POST requests occurring within seconds of a flagged cookie authentication event — this indicates a full VPN session was established.
If you are running a SIEM, routing PAN-OS GlobalProtect logs and setting alerts on the above patterns is straightforward and directly actionable.
A note on the CVSS score
The original CVSSv4 score for CVE-2026-0257 was 4.7: medium severity. That score has since been updated to 7.8 High by Palo Alto Networks, and in practice the vulnerability should be treated as critical.
CVSS attempts to be a context-free measure of base exploitability and impact, but for a vulnerability like this, context is everything. The affected component is a VPN gateway: its entire purpose is to grant access to the internal network. An authentication bypass on a VPN gateway does not produce some local, isolated impact; it produces unauthorized internal network access, which is effectively the starting point for every subsequent stage of an intrusion.
The gap between the initial CVSS score and the real-world severity is a useful reminder to assess vulnerabilities in the context of what the affected system does, not just what the formula produces.
Summary
| CVE | CVE-2026-0257 |
| Type | Authentication Bypass (CWE-565: Reliance on Cookies without Validation and Integrity Checking) |
| Component | PAN-OS GlobalProtect portal and gateway |
| CVSS Score | 7.8 High (CVSSv4, updated May 29, 2026; originally 4.7 Medium) |
| Affected | PAN-OS 10.2, 11.1, 11.2, 12.1; Prisma Access 10.2, 11.2 (when authentication override cookies are enabled with a shared certificate) |
| Not affected | Panorama, Cloud NGFW; deployments without authentication override cookies enabled |
| Discovered by | Palo Alto Networks internal security research teams |
| Disclosed | May 13, 2026 |
| Active exploitation | Confirmed from May 17, 2026 (Rapid7 MDR); second wave May 21, 2026 |
| CISA KEV | Added May 29, 2026 |
| Trigger condition | Authentication override cookies enabled + authentication override certificate shared with another feature (e.g. HTTPS service) |
| Impact | Unauthorized VPN connection established; internal network access in confirmed cases |
| Immediate mitigations | Disable authentication override cookies; or dedicate a new certificate exclusively to authentication override |
| Full fix | Upgrade to the fixed PAN-OS version for your release train (see advisory) |
| Known threat actor IOCs | IPs: 104.207.144.154, 146.19.216.119, 146.19.216.120, 146.19.216.125, 209.99.191.137, 79.130.26.202; MAC: aa:bb:cc:dd:ee:ff; Hostnames: GP-CLIENT, DESKTOP-GP01, Jocker |
Active exploitation is confirmed, the configuration that triggers this vulnerability is common, and the impact - unauthorized VPN access to your internal network - is as consequential as infrastructure vulnerabilities get. The mitigation is a configuration change that can be made right now without a maintenance window. The patch is available. There is no good reason for this to wait.
If you need help determining whether your GlobalProtect configuration is vulnerable, reviewing your authentication logs for evidence of prior exploitation, or deploying detection coverage across your Palo Alto estate, get in touch.