Vulnerability Analysis

CVE-2026-0257: PAN-OS GlobalProtect Authentication Bypass — What It Is & How to Fix It

Executive Summary

CVE-2026-0257 is an authentication bypass vulnerability in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS software that allows unauthenticated remote attackers to forge authentication override cookies and establish unauthorized VPN connections — including as the local administrator account. Palo Alto Networks confirmed active exploitation beginning May 17, 2026; CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on May 29, 2026 with a federal remediation deadline of June 19, 2026. Organizations running GlobalProtect with authentication override cookies enabled must patch or mitigate immediately.

1. What Is This Vulnerability?

GlobalProtect supports authentication override cookies as a performance optimization. Instead of repeating full multi-factor authentication (MFA) on every reconnect, the portal or gateway encrypts a cookie containing identity and session metadata and hands it to the client. On subsequent connections, the client presents this cookie and is admitted without repeating the full auth flow.

The vulnerability stems from certificate reuse. If the certificate used to encrypt and decrypt authentication override cookies is the same certificate used for the device's HTTPS (web) service — which is a common default configuration — then the certificate's public key is publicly exposed via normal TLS handshakes. An attacker can:

  1. Retrieve the public key from the device's HTTPS certificate (no credentials required).
  2. Craft a malicious cookie payload that claims to authenticate as any user (including admin).
  3. Encrypt the payload using the exposed public key.
  4. Submit the forged cookie to the GlobalProtect portal or gateway.
  5. Because the decryption succeeds (the server's private key correctly decrypts it) and no signature verification is performed post-decryption, the server trusts the forged cookie as legitimate.
  6. The attacker is granted authenticated VPN access with the identity they specified.

Attack Vector

  • Network-based, unauthenticated, no user interaction required
  • Attacker needs only HTTPS access to the GlobalProtect portal or gateway (typically internet-exposed)
  • Requires that authentication override cookies are enabled (Accept Cookie or Generate Cookie) AND the encryption certificate is shared with another exposed service

Real-World Impact

Rapid7 MDR observed two distinct exploitation waves in May 2026:

  • Wave 1 (May 17–18): Attackers authenticated as local admin accounts using forged cookies; exploitation traffic originated from infrastructure hosted at Vultr.
  • Wave 2 (May 21): Second wave from infrastructure attributed to Dromatics Systems.

Both waves used a consistent spoofed MAC address, indicating a single threat actor. Attackers successfully established VPN sessions as high-privilege accounts, enabling lateral movement and potential full network access behind the firewall perimeter.

2. Who Is Affected?

The vulnerability affects any PAN-OS firewall with GlobalProtect configured when both of the following conditions are true:

  1. Authentication override is enabled (Generate Cookie and/or Accept Cookie is checked in the GlobalProtect portal or gateway configuration).
  2. The certificate used for GlobalProtect authentication override is shared with another service that exposes it publicly (most commonly the HTTPS/management web interface).

Affected PAN-OS versions:

Version Branch Vulnerable Through Fixed In
PAN-OS 10.2 10.2.18-h5 and earlier 10.2.18-h6
PAN-OS 11.1 11.1.14 and earlier 11.1.15
PAN-OS 11.2 11.2.11 and earlier 11.2.12
PAN-OS 12.1 12.1.4-h5 / 12.1.6 and earlier 12.1.4-h6 / 12.1.7

Not affected: Panorama, Cloud NGFW, and Prisma Access are not impacted.

GlobalProtect deployments where authentication override cookies are disabled are not vulnerable, regardless of certificate configuration.

3. How to Detect It (Testing)

Check Your Configuration (Is Your Device Potentially Vulnerable?)

Before testing, determine if authentication override cookies are enabled:

  1. Log in to the PAN-OS web interface.
  2. Navigate to Network → GlobalProtect → Portals → [Portal Name] → Agent → [Agent Config].
  3. Check the Authentication tab.
  4. Look for Generate Cookie and Accept Cookie settings — if either is enabled, authentication override is active.
  5. Identify the Cookie Encryption Certificate field (or the certificate in use for GlobalProtect HTTPS).
  6. Check Device → Certificate Management → Certificates to see if that same certificate is also used for the web interface (SSL/TLS service profile).

Manual Testing Steps

Step 1: Retrieve the device's public key from its HTTPS certificate.

openssl s_client -connect <GP-PORTAL-IP>:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout > portal_public_key.pem

Step 2: Check whether the same certificate fingerprint appears in the GlobalProtect portal response (confirming reuse).

# Get the cert fingerprint from the HTTPS endpoint
openssl s_client -connect <GP-PORTAL-IP>:443 </dev/null 2>/dev/null \
  | openssl x509 -fingerprint -noout -sha256

Compare this fingerprint to what is shown in the PAN-OS certificate management UI for the GlobalProtect cookie encryption certificate. If they match, the device is in the vulnerable configuration.

Step 3: Check PAN-OS version against the affected version table above.

Automated Scanning

  • Tool: Tenable Nessus or Qualys
    Search for plugin/check named "CVE-2026-0257" or "Palo Alto GlobalProtect Authentication Bypass" in your scanner's vulnerability library. Both vendors have published checks following CISA's KEV addition.

  • Tool: nuclei (ProjectDiscovery)

    nuclei -u https://<GP-PORTAL-IP> -t cves/2026/CVE-2026-0257.yaml -v

    Community-contributed templates for this CVE are available in the nuclei-templates repository.

  • Tool: Palo Alto's own Security Posture Assessment (SPA) — run via the support portal to assess your fleet configuration against this and related issues.

Code Review / Configuration Checklist

  • Are authentication override cookies enabled in any GlobalProtect portal or gateway configuration?
  • Is the certificate used for cookie encryption the same certificate used for the device HTTPS management interface?
  • Is the certificate used for cookie encryption the same certificate used for any other publicly-accessible service on the device?
  • Is the PAN-OS version below the fixed threshold for the installed branch?
  • Are GlobalProtect portals/gateways directly internet-accessible?

4. How to Fix It (Mitigation)

Option A: Apply the Patch (Recommended)

Upgrade to the patched PAN-OS version for your branch:

  1. Confirm your current version: CLI → show system info | match sw-version
  2. Download the target hotfix from the Palo Alto Networks Customer Support Portal.
  3. Follow standard PAN-OS upgrade procedures: 
    # Upload and install via CLI
request system software install version <target-version>
# Reboot after completion
request restart system
  4. After upgrade, verify: show system info | match sw-version
  5. Re-run your configuration check (see Section 3) to confirm the patched version is in place.

Option B: Immediate Workaround (If Patching Is Delayed)

Disable authentication override cookies. This eliminates the attack surface without requiring a software upgrade. Users will be required to complete full authentication on every GlobalProtect connection.

  1. Navigate to Network → GlobalProtect → Portals → [Portal] → Agent → [Agent Config] → Authentication.
  2. Set Generate Cookie to No.
  3. Set Accept Cookie to No.
  4. Repeat for all configured Gateways: Network → GlobalProtect → Gateways → [Gateway] → Agent → [Client Config] → Authentication.
  5. Commit the change.

Option C: Use a Dedicated Cookie Encryption Certificate

If you require authentication override cookies for operational reasons, issue a separate, non-publicly-exposed certificate exclusively for cookie encryption:

  1. Generate a new self-signed certificate: Device → Certificate Management → Certificates → Generate.
    • Set a descriptive name (e.g., gp-cookie-encryption-internal).
    • Do not assign this certificate to any HTTPS service profile or externally-exposed interface.
  2. In each GlobalProtect portal and gateway agent config, set the Cookie Encryption Certificate field to this new dedicated certificate.
  3. Commit and verify.

Since this certificate's public key is never exposed via TLS, the forging attack vector is eliminated even with cookies still enabled.

Code Fix Example

Before (vulnerable — shared certificate):

<!-- GlobalProtect Portal Agent Config -->
<authentication>
  <generate-cookie>yes</generate-cookie>
  <cookie-encrypt-cert>webui-default-cert</cookie-encrypt-cert>  <!-- Same as HTTPS cert! -->
  <accept-cookie>yes</accept-cookie>
</authentication>

After (safe — dedicated certificate):

<!-- GlobalProtect Portal Agent Config -->
<authentication>
  <generate-cookie>yes</generate-cookie>
  <cookie-encrypt-cert>gp-cookie-encryption-internal</cookie-encrypt-cert>  <!-- Dedicated, not exposed -->
  <accept-cookie>yes</accept-cookie>
</authentication>

Configuration Hardening

  • Restrict GlobalProtect portal/gateway management access to trusted IP ranges via security policies.
  • Enable Threat Prevention profiles on policies governing GlobalProtect traffic.
  • Review all certificates in use on the device and audit which are assigned to multiple services.
  • Enable Multi-Factor Authentication for GlobalProtect users at the identity provider level — this adds a layer of defense even if a cookie bypass occurs.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Attempt to forge a cookie using the old shared certificate's public key after applying the patch or workaround — confirm the device rejects it.
  • Scenario B: Verify legitimate GlobalProtect clients can still authenticate and connect normally.
  • Scenario C: If cookies were disabled (Option B workaround), verify users are prompted for full authentication on each new connection.

Security Test Cases

Test Case 1: Verify the vulnerability no longer exists

  • Precondition: Patch applied OR cookie encryption certificate replaced with a dedicated non-exposed cert.
  • Steps: Extract the public key from the device's HTTPS certificate (as in Section 3 Step 1). Attempt to forge an authentication override cookie encrypted with that public key and submit it to the GlobalProtect portal.
  • Expected Result: Authentication fails; device does not establish a VPN session for the forged cookie.

Test Case 2: Verify legitimate client connectivity

  • Precondition: Fix applied.
  • Steps: Connect a GlobalProtect client with valid credentials and MFA.
  • Expected Result: Client connects successfully and receives a valid tunnel.

Test Case 3: Version verification

  • Precondition: Upgrade performed.
  • Steps: Run show system info | match sw-version on the device CLI.
  • Expected Result: Output shows the patched version (e.g., 10.2.18-h6, 11.1.15, 11.2.12, 12.1.7, etc.).

Automated Tests

import ssl
import socket
import subprocess

def verify_cert_not_reused(host: str, gp_cert_cn: str) -> bool:
    """
    Check whether the HTTPS certificate CN matches the GP cookie cert CN.
    If they match, the device is in the vulnerable shared-cert configuration.
    """
    context = ssl.create_default_context()
    context.check_hostname = False
    context.verify_mode = ssl.CERT_NONE
    with socket.create_connection((host, 443), timeout=5) as sock:
        with context.wrap_socket(sock, server_hostname=host) as ssock:
            cert = ssock.getpeercert(binary_form=False)
            https_cn = dict(x[0] for x in cert.get('subject', [])).get('commonName', '')
    match = https_cn.strip().lower() == gp_cert_cn.strip().lower()
    if match:
        print(f"[VULNERABLE] HTTPS cert CN '{https_cn}' matches GP cookie cert CN '{gp_cert_cn}'")
    else:
        print(f"[OK] HTTPS cert CN '{https_cn}' differs from GP cookie cert CN '{gp_cert_cn}'")
    return not match

# Example usage
verify_cert_not_reused("192.168.1.1", "gp-cookie-encryption-internal")

6. Prevention & Hardening

Best Practices

  • Principle of certificate separation: Never reuse the same certificate across services with different exposure levels. A certificate exposed on a public HTTPS interface should never also serve as a secret key for internal authentication tokens.
  • Periodic certificate audits: Regularly review which certificates are assigned to which services, especially after any configuration change or firewall migration.
  • Least-privilege VPN design: Configure GlobalProtect HIP (Host Information Profile) checks so that even a successful authentication bypass cannot proceed without meeting endpoint compliance requirements.
  • MFA at the IdP layer: Enforce MFA through SAML or RADIUS at the identity provider level. Even if an attacker bypasses the cookie check, certificate-based or TOTP-based MFA at the backend IdP adds a meaningful additional barrier.
  • Segment post-VPN access: Apply strict security policy rules to GlobalProtect tunnel zones — VPN users should not have unrestricted lateral movement once connected.

Monitoring & Detection

Log-based detection (PAN-OS):

Navigate to Monitor → Logs → System and filter for authentication events associated with GlobalProtect. Look for:

  • Authentication events using local admin accounts from unexpected source IPs.
  • Authentication events that do not correlate with known client MAC addresses.
  • Multiple authentication attempts in rapid succession from a single IP (cookie forgery brute-force attempts).

SIEM / EDR rules (Rapid7 InsightIDR signatures):

  • Suspicious Authentication – Palo Alto GlobalProtect Cookie Authentication to Local Admin Account
  • VPN Authentication via Spoofed MAC Address

Threat intelligence: Monitor CISA KEV updates and Palo Alto PSIRT advisories. Subscribe to Palo Alto's security advisory mailing list at security-announce@paloaltonetworks.com.

Network-level: Alert on GlobalProtect authentication traffic from Tor exit nodes, hosting providers (e.g., Vultr, DigitalOcean), or IP ranges with no prior connection history to your organization.

References

Latest from the blog

See all →