Overview
On May 13, 2026, Palo Alto Networks published a security 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.
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. At this time, Rapid7 is unable to confirm why VPN assignment occurred only for a subset of exploited customers. 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 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.
Known Indicators of Compromise
Low-cost hosting providers; frequent origin of sustained threat campaigns.
Item | Description |
104.207.144.154 | Threat actor source IP |
146.19.216.119 | Threat actor source IP |
146.19.216.120 | Threat actor source IP |
146.19.216.125 | Threat actor source IP |
DESKTOP-GP01 | Machinename observed in the GlobalProtect logs alongside Windows authentications first observed on May 21, 2026 |
GP-CLIENT | Machinename observed in the GlobalProtect logs alongside Linux authentications first observed on May 17, 2026 |
aa:bb:cc:dd:ee:ff | Spoofed MAC address observed in both waves of successful exploitation |
Updates
- May 29, 2026: Initial publication.
- May 29, 2026: Added CISA KEV addition.
SOCIAL SHARE CARD GENERATOR