Overview

On May 13, 2026, Palo Alto Networks published a security advisory for CVE-2026-0257, a medium severity authentication bypass affecting PAN-OS and Prisma Access when a specific configuration is present. Successful exploitation of this vulnerability allows a remote unauthenticated attacker to successfully establish a VPN connection through the GlobalProtect gateway of an affected appliance.

Rapid7 MDR identified successful exploitation across numerous customers, however we did not observe any indication of successful lateral movement from the devices. The earliest date for observed exploitation was May 17, 2026.  As of May 29, 2026,  this vulnerability has been added to the CISA KEV.

The CVE was originally assigned a CVSSv4 score of 4.7, medium severity. Due to the circumstances surrounding this vulnerability Rapid7 urges that organizations treat this as a critical vulnerability. An authentication bypass in an edge facing enterprise VPN appliance can have significant impact to affected organizations. As such, organizations running affected appliances are urged to upgrade to a vendor supplied patch on an urgent basis.

Note that, as of May 29, Palo Alto Networks updated their security advisory to reflect a change in the CVSS score. The CVSSv4 score was changed from 4.7 to 7.8, with high severity to inform their customers to patch with the highest urgency. 

Observed Attacker Behavior

On 2026-05-18 01:51:37 UTC, Rapid7 MDR responded to a 'Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity' alert. During the initial investigation, Rapid7 observed a suspicious cookie authentication to the local admin account across multiple customer environments from the same hosting provider, Vultr.

<14>May 18 01:51:37 palovpn-01 1,2026/05/18 01:51:37,010101010101,GLOBALPROTECT,0,2817,2026/05/18 01:51:37,vsys1,gateway-auth,login,Cookie,,admin,US,GP-CLIENT,104.207.144.154,0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,,Linux,"linux-64",1,,,"Auth latency: 78ms, profile: local_auth_profile",success,,0,,0,GP-Gateway,0101010101010101010,0x0,2026-05-18T01:51:37.264-05:00,,,,,,0,0,0,0,,palovpn-01,1,",

GlobalProtect Authentication Log

Rapid7 MDR analyzed the Palo Alto tech support files across the impacted customers and observed that Cloud Authentication Service (CAS) was disabled and the GlobalProtect portal or gateway had authentication override cookies enabled. Based on these findings, MDR analysts concluded that this was likely exploitation of CVE-2026-0257. Subsequent analysis by Rapid7 Labs confirmed this was accurate by validating a successful proof-of-concept.

Rapid7 MDR observed a second wave of exploitation on May 21st. Due to the consistent MAC address, Rapid7 believes both waves of exploitation are likely from the same threat actor (TA). However, the second wave of compromises originated from the hosting provider, Dromatics Systems. In this wave of exploitation, Rapid7 observed VPN IP assignment following the cookie authentication, granting them access to the internal network. Rapid7 observed POST requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp in the cases where a VPN tunnel was successfully established. The first submits security profile information and the second to establish the secure tunnel. Across multiple customers, Rapid7 observed successful exploitation via authentication probes using forged cookies, but the appliance accepted the cookie without a full VPN session being established in 8 out of 10 impacted MDR customers.

<14>May 21 01:54:39 FW-PA-A 1,2026/05/21 01:54:38,010101010101,GLOBALPROTECT,0,2818,2026/05/21 01:54:38,vsys1,gateway-auth,login,Cookie,,admin,US,DESKTOP-GP01,146.19.216.125,0.0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,Windows,"Microsoft Windows 10 Pro , 64-bit",1,,,"Auth latency: 1019ms, profile: SAML-o365-GP",success,,0,,0,GlobalProtect_External_Gateway,0101010101010101010 ,0x8000000000000000,2026-05-21T01:54:39.142-05:00,,,,,,30,241,35,0,,FW-PA-A,1,,",

GlobalProtect Authentication Log

Technical Analysis

Per the vendor advisory, we know the issue lies in a feature called “authentication override”. This feature allows a GlobalProtect portal or gateway to issue cookies to an authenticated user. The authenticated user can then use an authentication override cookie in future communications to the GlobalProtect portal or gateway in lieu of re-authenticating via credentials, akin to a bearer token. This is not a feature that is enabled by default.

We also know from reading the vendor advisory that the vulnerability requires a certain configuration in how certificates are used to encrypt and decrypt these authentication override cookies. Specifically, the certificate used to encrypt and decrypt authentication override cookies must not be the same certificate used for the GlobalProtect portal or gateway’s HTTPS service. This is a significant clue to how the vulnerability works.

To explore what an authentication override cookie looks like and how they are created, we can look at the implementation in the /usr/local/bin/gpsvc binary which implements the GlobalProtect service (Our testing appliance was running PAN-OS 10.2.8 in a vulnerable configuration). Inspecting the main_DoAuthLogin function, we see that if a HTTP form value of either portal-userauthcookie or portal-prelogonuserauthcookie is present during a POST request to /ssl-vpn/login.esp, authentication will be performed by a call to main_AuthWithCookie. This function will take the incoming encrypted cookie value stored in either portal-userauthcookie or portal-prelogonuserauthcookie, decrypt it and extract the cookies user name, domain name, host id, client OS, remote address, and timestamp (as auth override cookies have a lifetime after which they will expire).

void __gostk main_AuthWithCookie(
        main_GpTask_0 *t,
        paloaltonetworks_com_libs_common_AuthProfile *authProfile,
        string authCookie,
        string key,
        string stage,
        uint32 cookieLifetime,
        uint32 eventId,
        uint32 netMask,
        bool checkSrcIp,
        main_authResult_0 *result,
        string defaultDescription)
{
// ...

  ts = 0;
  errorCode = 0;
  user = 0;
  domain = 0;
  hostId = 0;
  clientOs = 0;
  remoteAddr = 0;
  result->retCode = 0;
  startTime = time_Now();
  result->cookie_auth_status = -1;
  t->Variables.authMethod.len = 6;
if ( *(_DWORD *)&runtime_writeBarrier.enabled )
    runtime_gcWriteBarrier();
else
t->Variables.authMethod.str = (uint8 *)"Cookie";
  str = authProfile->AuthProfileName.str;
  t->Variables.authProfile.len = authProfile->AuthProfileName.len;
if ( *(_DWORD *)&runtime_writeBarrier.enabled )
    runtime_gcWriteBarrier();
else
t->Variables.authProfile.str = str;
  v27 = main_DecryptAppAuthCookie(t, authCookie, key, &user, &domain, &hostId, &clientOs, &remoteAddr, &ts);

If we look at the main_DecryptAppAuthCookie function we can begin to see the problem. The incoming encrypted cookie is base64 decoded and then decrypted using a private key. The decrypted content is then trusted implicitly, with no signature verification of any kind occurring after decryption.

error __gostk main_DecryptAppAuthCookie(
        main_GpTask_0 *t,
        string authCookie,
        string privateCert,
        string *user,
        string *domain,
        string *hostId,
        string *clientOs,
        string *remoteAddr,
        int64 *ts)
{
// ...

  if ( privateCert.len )
  {
    *(retval_95DD80 *)&text[48] = paloaltonetworks_com_libs_common_DecryptRsaPrivateWithBase64Std(
                                    privateCert,
                                    (string)0LL,
                                    authCookie);

The implication here is that anyone who knows the public key for the certificate used by the authentication override feature to encrypt and decrypt cookies, can successfully forge and encrypt an arbitrary authentication override cookie. The question then becomes, how does an attacker learn the correct public key to use in this attack?

This brings us back to the vendor's advisory where they state “do not reuse the portal or gateway certificate, and do not share this certificate with other features or users”.

If a GlobalProtect portal or gateway has reused the certificate for encrypting and decrypting cookies with another feature, such as the HTTPS service of the portal or gateway, then a remote unauthenticated attacker can discover the public key for that certificate. In doing so the attacker will be able to successfully forge and encrypt arbitrary authentication override cookies. As these forged cookies will be successfully decrypted server side, they will be trusted and an authentication bypass will be achieved. An attacker can use a valid forged authentication override cookie to login and establish a VPN connection.

In addition to Exposure Command and InsightVM customers being able to assess their exposure with authenticated checks, a publicly available proof-of-concept script to test if an appliance is vulnerable to CVE-2026-0257 has been developed by Rapid7 Labs. The script will retrieve all certificates in the chain for the HTTPS service of either a GlobalProtect portal or gateway. Each certificate in the chain is iterated over and an authentication override cookie is forged using each certificate's public key. This forged cookie is then tested against the GlobalProtect portal or gateway, and the script reports back if authentication was successful or not. 

The usage of the script is shown below.

$ python3 forge_cookie.py --help
usage: forge_cookie.py [-h] --target TARGET [--port PORT] [--user USER] [--domain DOMAIN] [--host-id HOST_ID] [--client-os CLIENT_OS] [--client-ip CLIENT_IP] [--context {gateway,portal,both}] [--verbose]

Forge a GlobalProtect auth override cookie using the public key from TLS (CVE-2026-0257).

options:
  -h, --help            show this help message and exit
  --target TARGET       Target GP portal/gateway IP/hostname
  --port PORT           Target port (default: 443)
  --user USER           Username to forge cookie for (default: admin)
  --domain DOMAIN       Domain for cookie (default: empty)
  --host-id HOST_ID     Host ID for cookie (default: empty)
  --client-os CLIENT_OS
                        Client OS for cookie (default: Windows)
  --client-ip CLIENT_IP
                        Client IP in cookie (default: 0.0.0.0)
  --context {gateway,portal,both}
                        Context to test: gateway, portal, or both (default target)
  --verbose             Print full response

A successful invocation of the script against a vulnerable appliance is shown below. We can see the target's GlobalProtect gateway accepted a forged authentication override cookie using the second certificate in the chain.

$ python3 forge_cookie.py --target 192.168.86.99 --user haxor
[*] 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
  [-] Failure - Portal did not accepted the forged cookie

  Trying [1] CN=GP-Lab-CA
  [+] Success - Gateway accepted the forged cookie
  Cookie: ng9ygxlaclylNXeSHcakXZPK06Fno0svVirz6RhRtA5mDmOaZyg/KMxUuM5lRvm1Rn1Z6vqaWQQPvQOHzwJnyldOmhUKy+HDMgIYtJ/kk3ypMqmFE7BbmPxnSKxKcQQbNIcxgkrhCwuJKwybuq0aaPVNzN9BSWmh1QmZj7oLjTEo9ExAXrm951mqYhh3+MgBCScaYqP23WzrC+vzqJB74sHoMUuFWIF8/sMYDMpvENOoI4nXAFCaRYSruW9FQQy5VTzNifNWkrYcdzDCXKiP8v4G098/2QoBbVoyHBZwbgHGBsRU3ZeSgoHjrhjxyotIshKVssUs8CRpuG2HlZBM0Q==

We can observe the successful authentication via the management interface, as shown below. The two initial failures correspond to the first certificate being used which was the incorrect certificate.

Figure 1: PAN-OS Management Interface

Mitigation Guidance

According to the Palo Alto Networks advisory, the following product versions are affected by CVE-2026-0257:

Affected products must have the authentication override feature enabled in either the GlobalProtect portal or gateway, and must reuse the authentication override cookie encryption and decryption certificate with another feature in order to be vulnerable. As a mitigation, affected products should either disable the authentication override feature or generate a new certificate to use exclusively for the authentication override feature.

Please refer to the vendor advisory for the latest guidance.

Rapid7 Customers

Managed Detection Response (MDR)

The following detection rules are available for InsightIDR and Managed Detection Response (MDR) customers:

• Suspicious Authentication - Palo Alto GlobalProtect Cookie Authentication to Local Admin Account

• Threat Intel (Rapid7 MDR SOC/IR) - VPN Authentication via Spoofed MAC Address

• Threat Intel (Rapid7 MDR SOC/IR) - Indicator of Compromise Observed 

• Suspicious VPN Authentication - Palo Alto GlobalProtect Login via Default Hostname

• Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity

• Suspicious VPN Authentication - Local Account

• Suspicious Authentication - Vultr

• Suspicious Authentication - Dromatics Systems

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0257 using an authenticated check available since the May 15 content release.

IntelHub

IntelHub customers can look into the Platform to search for more details and correlate the indicators of compromise with the data from their own environment.

Known Indicators of Compromise

Low-cost hosting providers; frequent origin of sustained threat campaigns.

Updates

• May 29, 2026: Initial publication.
• May 29, 2026: Added CISA KEV addition.
• June 2, 2026: Added IntelHub information under Rapid7 Customers section, updated to reflect Palo Alto Networks change to security advisory (CVSS score change). Added 3 new IOCs (2 IPs and 1 machinename).
• June 3, 2026: Added observed URI endpoints accessed for successful VPN connections to the Observed Attacker Behavior section.