CVE-2026-0257, The GlobalProtect Auth Bypass That Turns Cookies Into VPN Access

CVE-2026-0257 is an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS. Under the right configuration, a remote unauthenticated attacker can bypass security restrictions and establish an unauthorized VPN connection. Palo Alto Networks says Panorama and Cloud NGFW are not impacted, but affected PAN-OS and Prisma Access deployments require urgent attention because the vulnerable path sits at the remote-access edge, where a single authentication failure can become network access. (Palo Alto Networks Security)

The most important detail is not the CVE number alone. The key is the configuration. The issue affects firewalls with a GlobalProtect portal or gateway configured when authentication override cookies are enabled and a specific certificate configuration exists. Palo Alto Networks’ advisory points administrators to the portal and gateway configuration pages where “Generate cookie for authentication override” and “Accept cookie for authentication override” can be checked. (Palo Alto Networks Security)

The second important detail is exploitation status. Palo Alto Networks updated the advisory on May 29, 2026 and said it had become aware of limited exploit attempts against unpatched PAN-OS devices without mitigations applied. Rapid7 MDR reported successful exploitation across numerous customers, with the earliest observed exploitation on May 17, 2026, and NVD shows that CVE-2026-0257 was added to CISA’s Known Exploited Vulnerabilities catalog with a June 1, 2026 due date for required federal remediation. (Palo Alto Networks Security)

That combination changes the operational priority. This is not a theoretical edge-case bug that can wait for the next routine maintenance window. It is an authentication bypass in a VPN component, it has public technical analysis, it has active exploitation reporting, and it has a clear configuration condition that defenders can verify.

What defenders need to know first

Field	Current public information
CVE	CVE-2026-0257
Vendor	Palo Alto Networks
Affected area	GlobalProtect portal and gateway in PAN-OS, and certain Prisma Access versions
Vulnerability class	Authentication bypass tied to authentication override cookies
Weakness type	CWE-565, reliance on cookies without validation and integrity checking
Attack vector	Network
Privileges required	None
User interaction	None
Practical impact	Unauthorized VPN connection through an affected GlobalProtect gateway
Required exposure condition	GlobalProtect portal or gateway configured, authentication override cookies enabled, and a vulnerable certificate configuration
Exploitation status	Palo Alto Networks reports limited exploit attempts; Rapid7 reports observed exploitation across multiple MDR customers
CISA KEV status	Listed in CISA KEV via NVD, with required action to apply vendor mitigations or discontinue use if mitigations are unavailable
Not impacted according to vendor	Panorama and Cloud NGFW

Palo Alto Networks’ own advisory rates the issue as High with CVSS-BT 7.8 in CVSS v4.0 terms, while NVD lists a CVSS v3.1 base score of 9.1 Critical. That scoring difference is worth noting, but it should not distract from the risk. Rapid7 explicitly recommends treating the issue as critical because an authentication bypass in an edge-facing enterprise VPN appliance can have major impact. (Palo Alto Networks Security)

The practical question is simple: can an unauthenticated party convince GlobalProtect that it has a valid authentication override cookie? If the answer is yes, the attacker may not need a password, MFA prompt, or stolen session from a real user to start interacting with the VPN authentication path.

Why a VPN authentication bypass outranks its score

Security teams often triage by CVSS, and CVSS is useful. It gives organizations a shared way to discuss exploitability and impact. But CVSS is not a substitute for context.

CVE-2026-0257 sits on a remote-access control point. A public-facing VPN service is not the same as a vulnerable internal-only admin utility or a local client crash. VPN gateways bridge the public internet and trusted enterprise networks. They terminate identity, establish tunnels, assign internal addresses, and often become the first security boundary for remote employees, contractors, privileged administrators, and third-party support users.

An authentication bypass at that boundary has several properties that make it dangerous:

Risk driver	Why it matters
Internet exposure	GlobalProtect portals and gateways are commonly reachable from the public internet so remote users can connect.
Identity boundary	The vulnerable component is part of the process that decides who is allowed to connect.
VPN trust	Successful authentication may result in VPN IP assignment and access to internal routes.
Log ambiguity	Cookie-based authentication may look like a legitimate convenience flow unless defenders know what fields to inspect.
Configuration specificity	Teams may underestimate the issue if only some configurations are vulnerable.
Active exploitation	Public reports describe observed exploitation, making passive patch planning unsafe.

Rapid7’s reporting illustrates the difference between a theoretical weakness and a working attack path. Its MDR team saw suspicious cookie authentication to a local admin account across customer environments, later observed a second wave, and stated that some cases resulted in VPN IP assignment following cookie authentication. Rapid7 also said it had not observed successful lateral movement from the affected devices at the time of publication, which is important: the public evidence supports urgent response, not unsupported claims of widespread post-compromise activity. (Rapid7)

That distinction matters. Defenders should treat CVE-2026-0257 as urgent because of where it lives and because exploitation has been observed. They should not invent facts beyond the available evidence. The right response is fast patching, careful log review, configuration correction, and controlled validation.

How GlobalProtect authentication override cookies work

GlobalProtect has separate portal and gateway interactions. A user may authenticate to a portal to receive configuration and then authenticate to a gateway to establish VPN access. In environments with MFA or dynamic passwords, this can create repeated prompts. Authentication override cookies exist to reduce that friction.

Palo Alto Networks’ GlobalProtect documentation explains that cookie authentication can reduce the number of times users must log in to the portal and gateway or enter multiple OTPs. After the portal or gateway deploys an authentication cookie to the endpoint, the portal and gateway rely on the cookie to authenticate the user, evaluating whether the cookie remains valid based on the configured lifetime. If the cookie expires, GlobalProtect prompts the user to authenticate again and issues a replacement cookie after successful authentication. (Palo Alto Networks TechDocs)

The portal configuration exposes this directly. The “Generate cookie for authentication override” option configures the portal to generate encrypted endpoint-specific cookies after first authentication. The “Accept cookie for authentication override” option lets the portal authenticate endpoints through a valid encrypted cookie. Palo Alto’s documentation also states that the portal verifies that the cookie was encrypted by the portal, decrypts it, and then authenticates the user. (Palo Alto Networks TechDocs)

This kind of feature is not inherently bad. It is a common tradeoff in enterprise identity systems: reduce repeated prompts while preserving a bounded trust artifact. The security model depends on strict validation. A cookie that substitutes for re-authentication must be treated like a sensitive credential. It should be hard to forge, tightly scoped, bound to the intended context, protected by appropriate cryptography, and invalidated when the underlying trust conditions change.

CVE-2026-0257 is serious because the public analysis indicates that, in vulnerable configurations, the authentication override cookie trust boundary can be crossed without prior authentication.

The public technical root cause

Rapid7’s technical analysis provides the clearest public explanation of how the bug works. It describes authentication override cookies as bearer-token-like artifacts: once a legitimate user authenticates, the portal or gateway can issue a cookie that the user later presents instead of re-entering credentials. Rapid7 notes that this feature is not enabled by default. (Rapid7)

According to Rapid7, the affected code path in the GlobalProtect service handles cookie authentication during requests to /ssl-vpn/login.esp. If form values such as portal-userauthcookie or portal-prelogonuserauthcookie are present, the service can enter a cookie authentication path. Rapid7’s reverse-engineering summary says the encrypted cookie is base64-decoded and decrypted with a private key, and that the decrypted content is then trusted implicitly without additional signature verification. (Rapid7)

That is the authentication design problem in plain language: decryption alone is not the same as integrity validation. If a server accepts decrypted fields as authoritative identity data, and an attacker can produce ciphertext that decrypts successfully under the server’s private key, then the server may treat attacker-controlled identity claims as valid.

Rapid7’s analysis ties this to certificate reuse. If the certificate used for authentication override cookie encryption and decryption is reused with another feature, such as the portal or gateway HTTPS service, a remote unauthenticated attacker can discover the public key from the TLS certificate chain. Rapid7 states that the attacker can then forge and encrypt arbitrary authentication override cookies that the server will decrypt and trust, achieving authentication bypass and potentially establishing a VPN connection. (Rapid7)

That explanation also clarifies why Palo Alto Networks’ mitigation guidance focuses on a dedicated certificate for authentication override cookies. If the certificate is exclusive to the cookie function and is not exposed through another service, the attacker should not be able to obtain the public key in the same way. Palo Alto Networks also recommends disabling Authentication Override as a mitigation. (Palo Alto Networks Security)

Affected versions and fixed releases

Palo Alto Networks lists affected and unaffected versions in its advisory. The table below consolidates the main version information for operational use. Always check the vendor advisory before making production changes because hotfix guidance can change.

Product line	Affected versions	Fixed or unaffected versions	Notes
Cloud NGFW	None	All	Palo Alto Networks says no action is needed for Cloud NGFW.
PAN-OS 12.1	Earlier than 12.1.4-h6 and earlier than 12.1.7	12.1.4-h6 or later in that branch, or 12.1.7 or later	Upgrade guidance depends on the minor branch in use.
PAN-OS 11.2	Earlier than 11.2.4-h17, 11.2.7-h14, 11.2.10-h7, and 11.2.12	11.2.4-h17, 11.2.7-h14, 11.2.10-h7, 11.2.12 or later	Palo Alto lists several fixed branch targets.
PAN-OS 11.1	Earlier than 11.1.4-h33, 11.1.6-h32, 11.1.7-h6, 11.1.10-h25, 11.1.13-h5, and 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 or later	Upgrade to the relevant fixed release or a later supported branch.
PAN-OS 10.2	Earlier than 10.2.7-h34, 10.2.10-h36, 10.2.13-h21, 10.2.16-h7, and 10.2.18-h6	10.2.7-h34, 10.2.10-h36, 10.2.13-h21, 10.2.16-h7, 10.2.18-h6 or later	Unsupported older PAN-OS versions should move to a supported fixed version.
Prisma Access 11.2	Earlier than 11.2.7-h13	11.2.7-h13 or later	Palo Alto says Prisma Access is being actively upgraded according to customer upgrade schedules.
Prisma Access 10.2	Earlier than 10.2.10-h36	10.2.10-h36 or later	Follow Palo Alto’s Prisma Access guidance and schedule.
Panorama	Not impacted by this issue	Not applicable	Panorama is not listed as impacted for CVE-2026-0257.

The vendor also notes a post-upgrade behavior that matters for help desks: if the firewall is configured to use an authentication override cookie for the GlobalProtect portal or gateway, the fix regenerates the cookie using a more secure method. GlobalProtect users will need to re-authenticate once after the PAN-OS upgrade even if they already have a valid cookie. (Palo Alto Networks Security)

That user-facing impact is not a reason to delay patching. It is a reason to communicate clearly before the maintenance window.

How to decide whether your environment is exposed

A good exposure check should answer five questions in order.

Question	Why it matters	What to do
Are you running an affected PAN-OS or Prisma Access version	CVE-2026-0257 is version-specific	Compare your versions to the fixed versions in the Palo Alto advisory.
Is GlobalProtect portal or gateway configured	The vulnerable feature path is tied to GlobalProtect portal or gateway	Inventory internet-facing and internal GlobalProtect deployments.
Are authentication override cookies enabled	The issue requires authentication override cookie use	Check portal and gateway settings for generate or accept cookie options.
Is the cookie certificate dedicated	Certificate reuse is central to the public exploitation analysis	Confirm the authentication override cookie certificate is not reused for HTTPS or other features.
Are there historical indicators	Exploitation may have occurred before patching	Review GlobalProtect authentication logs, VPN sessions, source IPs, usernames, machine names, and MAC addresses.

Palo Alto Networks gives specific UI paths. For the portal, go to Network, GlobalProtect, Portals, select the portal name, open the Agent tab, select the Agent Configuration profile, open Authentication, and check whether “Generate cookie for authentication override” or “Accept cookie for authentication override” is selected. For the gateway, go to Network, GlobalProtect, Gateways, select the gateway name, open the Agent tab, select Client Settings, open Authentication Override, and check whether “Accept cookie for authentication override” is selected. (Palo Alto Networks Security)

That check should be performed on every relevant portal and gateway, not just on the most visible production VPN endpoint. Large organizations often have regional gateways, legacy gateways, emergency access gateways, test portals, acquisition networks, and staging appliances that are not tracked in the same change-management path as the primary remote-access service.

Safe asset and certificate checks

The following commands are intended for authorized defensive review of systems you own or are explicitly allowed to test. They do not perform exploitation. They help you inventory exposed GlobalProtect endpoints and inspect TLS certificate material so you can compare it with your authentication override cookie certificate configuration.

# Identify the certificate chain presented by an authorized GlobalProtect endpoint.
# Replace vpn.example.com with your own portal or gateway hostname.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ { print }' \
  > gp_tls_chain.pem

# Print certificate subjects and issuers from the saved chain.

awk 'BEGIN {n=0} /BEGIN CERTIFICATE/ {n++; file="cert-" n ".pem"} {print > file}' gp_tls_chain.pem

for cert in cert-*.pem; do
  echo "=== $cert ==="
  openssl x509 -in "$cert" -noout -subject -issuer -serial -fingerprint -sha256
done

Use this output to compare the public TLS certificate chain with the certificate selected in the GlobalProtect authentication override cookie configuration. The defensive question is not “can I forge a cookie?” The question is “did we reuse the same certificate material in a way the vendor warns against?”

For inventory at scale, use a controlled asset list rather than internet-wide scanning.

# Example input: one hostname per line in authorized_gp_endpoints.txt
# Output: certificate fingerprints for internal review.

while read -r host; do
  echo "### $host"
  timeout 10 openssl s_client -connect "${host}:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
    | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ { print }' \
    | openssl x509 -noout -subject -issuer -serial -fingerprint -sha256 2>/dev/null
done < authorized_gp_endpoints.txt

The result should be reviewed alongside configuration exports, firewall UI checks, and change records. A certificate fingerprint alone does not prove exposure. It is one piece of evidence in a configuration audit.

What exploitation has looked like publicly

Rapid7’s reporting gives defenders concrete behaviors to look for. In one wave, Rapid7 observed suspicious cookie authentication to a local admin account across multiple customer environments from the same hosting provider, Vultr. In a second wave on May 21, 2026, Rapid7 observed activity from Dromatics Systems and saw VPN IP assignment following cookie authentication in some cases, granting access to the internal network. Rapid7 believed both waves were likely from the same threat actor because of a consistent MAC address. (Rapid7)

Rapid7 also reported uncertainty that defenders should preserve. It could not confirm why VPN assignment happened only for a subset of exploited customers. Across multiple customers, it observed successful exploitation through authentication probes using forged cookies, but the appliance accepted the cookie without a full VPN session in 8 out of 10 impacted MDR customers. (Rapid7)

That matters during incident response. A “cookie auth success” without a full VPN session is not automatically harmless. It may indicate probing, failed follow-through, environmental constraints, or partial exploitation. It should still trigger review, especially if the username, source IP, hostname, MAC address, client OS, or auth profile does not match normal user behavior.

Rapid7 published several indicators that can help seed hunts, including source IPs, machine names, and a spoofed MAC address observed in both waves. It also listed detection themes such as cookie authentication to a local admin account, spoofed MAC address, default hostname, local account logon, and suspicious authentication from Vultr or Dromatics Systems. (Rapid7)

Do not stop at published IOCs. They are useful starting points, not a complete detection strategy. Attackers can change VPS providers, IP addresses, hostnames, usernames, and MAC values.

Detection logic for GlobalProtect logs

GlobalProtect authentication logs are the center of the first detection pass. Rapid7’s sample log lines include GLOBALPROTECT, gateway-auth, login, Cookie, a username, source IP, machine name, client OS, auth profile, success status, and gateway name. Those fields are enough to build useful hunts even if your SIEM normalizes them differently. (Rapid7)

Look for patterns like these:

Signal	Why it matters	Example hunt logic
Cookie authentication for local admin	Public exploitation included suspicious cookie auth to local admin	auth_method=Cookie AND user=admin AND status=success
Cookie auth from new ASN or hosting provider	Rapid7 observed activity from hosting providers	Compare source ASNs against historical VPN login sources.
Cookie auth from impossible geography	VPN users usually have stable regions	Alert on new country or impossible travel with cookie auth.
New machine names	Rapid7 observed machine names such as GP-CLIENT and DESKTOP-GP01	Compare hostname values against endpoint inventory.
Spoofed or repeated MAC	Rapid7 observed the same spoofed MAC in both waves	Alert on MAC reuse across unrelated users or source IPs.
Cookie success followed by VPN IP assignment	This indicates authentication progressed into network access	Correlate auth logs with tunnel establishment and assigned IP events.
Cookie auth to sensitive profiles	Sensitive auth profiles should have tighter expectations	Alert on cookie auth for admin, break-glass, or privileged groups.
Cookie auth after mitigation deadline	Any post-mitigation event may indicate incomplete remediation	Compare events before and after patch or config change.

A basic log review can start with exported CSV or raw log files.

# Defensive log triage for exported GlobalProtect logs.
# Adjust file names and field assumptions to your environment.

grep -i "GLOBALPROTECT" gp-auth.log \
  | grep -i "gateway-auth" \
  | grep -i "Cookie" \
  | grep -i "success" \
  > cookie-auth-success.log

# Show top source IPs associated with cookie authentication successes.
awk -F',' '{print $19}' cookie-auth-success.log | sort | uniq -c | sort -nr | head -50

# Show top usernames.
awk -F',' '{print $14}' cookie-auth-success.log | sort | uniq -c | sort -nr | head -50

# Show top machine names, if present in the exported format.
awk -F',' '{print $23}' cookie-auth-success.log | sort | uniq -c | sort -nr | head -50

The field numbers above are illustrative because PAN-OS log export formats and SIEM pipelines differ. Validate them against your actual log format before making decisions.

A safer Python parser can preserve full rows and let analysts define the field mapping.

#!/usr/bin/env python3
"""
Defensive parser for exported GlobalProtect authentication logs.

Purpose:
- Find successful cookie-based GlobalProtect authentication events.
- Highlight unusual usernames, source IPs, machine names, and MAC values.
- Avoid exploit behavior. This script only reads local log files.

Usage:
  python3 gp_cookie_auth_hunt.py gp-auth.log
"""

from __future__ import annotations

import csv
import sys
from collections import Counter
from pathlib import Path


def looks_like_cookie_auth(row: list[str]) -> bool:
    joined = ",".join(row).lower()
    return (
        "globalprotect" in joined
        and "gateway-auth" in joined
        and "login" in joined
        and "cookie" in joined
        and "success" in joined
    )


def main() -> int:
    if len(sys.argv) != 2:
        print("Usage: python3 gp_cookie_auth_hunt.py <exported-log-file>")
        return 2

    path = Path(sys.argv[1])
    if not path.exists():
        print(f"File not found: {path}")
        return 2

    matching_rows: list[list[str]] = []

    with path.open("r", encoding="utf-8", errors="replace", newline="") as f:
        reader = csv.reader(f)
        for row in reader:
            if looks_like_cookie_auth(row):
                matching_rows.append(row)

    print(f"Cookie-based successful GlobalProtect auth rows: {len(matching_rows)}")

    # These indexes must be adjusted for your export format.
    candidate_indexes = {
        "username": 13,
        "source_ip": 18,
        "machine": 22,
        "mac": 25,
        "client_os": 29,
    }

    for label, idx in candidate_indexes.items():
        values = []
        for row in matching_rows:
            if len(row) > idx and row[idx].strip():
                values.append(row[idx].strip())
        print(f"\nTop {label} values")
        for value, count in Counter(values).most_common(20):
            print(f"{count:5d}  {value}")

    print("\nReview raw matching rows before taking action.")
    print("A match is a lead, not proof of compromise.")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

For SIEM teams, detection should correlate authentication, tunnel establishment, endpoint identity, and configuration state. A cookie authentication success from an unusual source is more important if it is followed by VPN IP assignment, internal DNS queries, SMB attempts, RDP attempts, privileged app access, or unusual egress from the assigned VPN address.

A generic Sigma-style sketch might look like this:

title: Suspicious GlobalProtect Cookie Authentication Success
id: 9b7fb2e0-2e5f-4b84-9a7f-gp-cookie-auth
status: experimental
description: Detects successful GlobalProtect cookie-based authentication events that may warrant review during CVE-2026-0257 response.
logsource:
  product: paloalto
  service: globalprotect
detection:
  selection:
    event_type|contains: "GLOBALPROTECT"
    subtype|contains: "gateway-auth"
    action|contains: "login"
    auth_method|contains: "Cookie"
    result|contains: "success"
  suspicious_user:
    username:
      - "admin"
      - "administrator"
  condition: selection
fields:
  - timestamp
  - src_ip
  - username
  - machine_name
  - client_os
  - auth_profile
  - gateway
  - assigned_ip
falsepositives:
  - Legitimate authentication override cookie use
  - Known managed endpoint reconnect behavior
level: medium

In a mature environment, that rule should be enriched with allowlists for known endpoints, identity provider logs, device posture, source ASN reputation, and business travel patterns.

Incident response workflow

Treat CVE-2026-0257 response as both a vulnerability-management task and a lightweight incident investigation. Patching without log review can miss pre-remediation access. Log review without patching leaves the door open.

Timeframe	Actions	Output
First 0 to 4 hours	Identify all GlobalProtect portals and gateways, confirm PAN-OS or Prisma Access version, check authentication override cookie settings, apply temporary mitigation if patching cannot start immediately	Exposure list, owner list, emergency mitigation decision
Same day	Upgrade internet-facing affected devices or disable Authentication Override, generate a dedicated authentication override cookie certificate where required, export GlobalProtect logs for at least the suspected exploitation window	Patched or mitigated edge, preserved logs
First 72 hours	Hunt for cookie auth anomalies, local admin cookie auth, unusual source IPs, odd machine names, spoofed MACs, VPN IP assignment after suspicious cookie auth, and internal activity from assigned VPN IPs	Triage report, confirmed or ruled-out suspicious sessions
First week	Rotate or retire risky certificate reuse, reduce exposed management paths, review unsupported PAN-OS, tune detections, validate fixes, document evidence and retest	Durable control improvements and audit-ready evidence
Ongoing	Monitor vendor updates, CISA KEV changes, new IOCs, and secondary exploitation reports	Updated detection and response posture

If suspicious access is confirmed, expand from VPN logs into identity, endpoint, DNS, proxy, firewall traffic, EDR, privileged access, and internal application logs. The first question is whether the attacker only probed the authentication path. The second is whether a tunnel was established. The third is whether the tunnel was used to touch internal assets.

Remediation and mitigation

The strongest fix is to upgrade to a fixed PAN-OS or Prisma Access version. Palo Alto Networks provides branch-specific upgrade targets and instructs unsupported PAN-OS users to upgrade to a supported fixed version. (Palo Alto Networks Security)

If immediate patching is not possible, Palo Alto Networks lists two mitigation paths:

Mitigation	What it does	Tradeoff
Use a dedicated certificate for Authentication Override cookies	Creates a certificate used exclusively for cookie encryption and decryption, not reused by the portal, gateway HTTPS service, other features, or users	Requires certificate handling, configuration review, and validation
Disable Authentication Override	Stops the portal or gateway from generating or accepting authentication override cookies	Users may see more authentication or MFA prompts

Palo Alto Networks’ wording is precise: generate a new certificate exclusively for authentication override cookies, store it securely, do not reuse the portal or gateway certificate, and do not share the certificate with other features or users. (Palo Alto Networks Security)

For many organizations, the fastest safe path is:

1. Disable Authentication Override on exposed GlobalProtect endpoints if the upgrade cannot be completed quickly.
2. Upgrade to the fixed release.
3. Reconfigure Authentication Override only if the user-experience need remains.
4. Use a dedicated cookie certificate.
5. Validate that portal and gateway behavior matches the intended design.
6. Hunt historical logs covering at least May 17, 2026 onward, with extra coverage before that date if logs are available.

The post-upgrade user re-authentication requirement should be handled as a planned support event. Tell users what to expect, when to expect it, and what support channel to use if GlobalProtect prompts unexpectedly.

Why MFA does not remove the need to patch

MFA is still important. It reduces risk from stolen passwords, credential stuffing, password reuse, and some phishing scenarios. But MFA does not eliminate CVE-2026-0257.

Authentication override cookies are specifically designed to reduce repeated authentication prompts after an initial successful login. Palo Alto’s documentation describes cookie authentication as a way to simplify the user experience and avoid repeated portal and gateway authentication or multiple OTP prompts. (Palo Alto Networks TechDocs)

If the vulnerable configuration lets an attacker forge an accepted authentication override cookie, the attacker is targeting the post-authentication shortcut, not the primary password prompt. In that scenario, MFA may never be reached in the way defenders expect.

This is the same reason session-token theft is dangerous in web applications protected by MFA. MFA protects the login ceremony. A valid session token may bypass the need to repeat that ceremony. The same mental model applies here: if a cookie can stand in for authentication, then cookie integrity is part of the authentication boundary.

Practical MFA-related recommendations:

Control	Recommendation
MFA on GlobalProtect	Keep it enabled. Do not weaken primary authentication.
Authentication override cookies	Patch, disable, or isolate with a dedicated certificate. Do not treat MFA as a replacement.
Cookie lifetime	Keep lifetimes as short as operationally tolerable, especially for gateways protecting sensitive routes.
Conditional access	Use device posture, trusted endpoint checks, and identity risk signals where available.
Monitoring	Alert on cookie authentication anomalies, not only failed MFA attempts.

Certificate reuse is the quiet failure mode

The public analysis makes certificate handling a core part of the risk. That is uncomfortable because certificate reuse often happens for operational convenience. A certificate already exists, it works, and teams reuse it to make a feature functional. Years later, that reuse becomes a security boundary violation.

Palo Alto Networks documentation for authentication override configuration says the portal and gateways should use the same certificate to encrypt and decrypt cookies. Other Palo Alto documentation for Prisma Access Agent and NGFW coexistence also describes configuring the authentication override certificate so the gateway can decrypt the cookie. (Palo Alto Networks TechDocs)

The important distinction is “same certificate across the cookie-auth trust path” versus “same certificate reused by unrelated features.” CVE-2026-0257 response should make teams inventory all places where the authentication override cookie certificate is used.

A good certificate review asks:

Review question	Good answer	Bad answer
Is the cookie certificate dedicated to authentication override	Yes, only used for cookie encryption and decryption	No, reused for HTTPS, portal, gateway, or other services
Is the private key protected	Stored only where required, with restricted administrative access	Exported, shared, or stored in unclear locations
Is certificate use documented	Change records identify purpose and owner	Nobody knows why the certificate exists
Is certificate rotation planned	Rotation process exists and is tested	Rotation would break VPN unexpectedly
Is use consistent across portal and gateway	Cookie path works by design	Inconsistent config creates fallback behavior and confusion

After remediation, record the certificate fingerprint, purpose, owner, creation date, expiration date, and approved usage. That turns the response from a one-time emergency into a long-term control improvement.

Safe validation without becoming the attacker

Rapid7 states that a publicly available proof-of-concept script exists to test whether an appliance is vulnerable. It retrieves certificates in the HTTPS chain, forges authentication override cookies using each public key, and reports whether authentication succeeds. (Rapid7)

That fact is useful for defenders, but it changes the ethics and safety of validation. Running an exploit-like test against systems you do not own or do not have explicit permission to test is not acceptable. Even inside an organization, a validation test that attempts authentication bypass against production VPN infrastructure should be approved, logged, scoped, and coordinated with operations.

A safer validation ladder looks like this:

Validation level	What it proves	Risk
Version check	The device is in or out of a known affected version range	Low
Configuration check	Authentication override cookies are enabled or disabled	Low
Certificate-use review	The cookie certificate is dedicated or reused	Low to medium
Log review	Suspicious cookie auth did or did not occur	Low
Lab reproduction	The exploit mechanism works in a controlled lab	Medium
Production exploit-style validation	The production endpoint accepts a forged cookie	High, requires approval

For most organizations, version check plus configuration check plus certificate review plus log review is enough to decide urgency. Production exploit-style validation should be rare and tightly controlled.

A practical validation record should include:

Target:
  vpn.example.com

Ownership:
  Confirmed internal asset under approved testing scope

PAN-OS version:
  11.2.x, checked on YYYY-MM-DD by <name>

GlobalProtect role:
  External gateway and portal

Authentication Override:
  Portal generate cookie: yes or no
  Portal accept cookie: yes or no
  Gateway accept cookie: yes or no

Certificate review:
  Cookie certificate name:
  Cookie certificate SHA-256 fingerprint:
  HTTPS certificate SHA-256 fingerprint:
  Reuse found: yes or no

Mitigation:
  Disabled Authentication Override or upgraded to fixed version

Log review:
  Time window:
  Suspicious cookie auth:
  Suspicious VPN IP assignment:
  Follow-on internal activity:

Final status:
  Not affected, mitigated, fixed, or requires further investigation

This is also where controlled AI-assisted workflows can be useful if they stay evidence-driven. For authorized testing, a tool such as Penligent can help structure CVE-focused validation, asset mapping, evidence capture, independent verification, and reporting around a defined scope rather than turning a CVE name into an uncontrolled scan. Its own workflow guidance emphasizes authorized testing, CVE-focused validation, proxy evidence, task trees, and independent verification; the homepage describes an AI-powered pentesting workflow oriented around finding vulnerabilities, verifying findings, and producing evidence-first reports. (Penligent)

The discipline matters more than the tool. A valid result should be reproducible from raw evidence, not accepted because an AI summary sounds confident.

Detection engineering beyond IOCs

Published IOCs are helpful for immediate triage. They are not enough for durable detection. A threat actor can switch IPs, providers, machine names, and MAC addresses in minutes.

Build behavioral detections around the authentication path.

Detection idea	Data sources	Why it survives IOC changes
Cookie auth to local admin or break-glass accounts	GlobalProtect auth logs, identity inventory	Attackers may target high-value local names even from new IPs.
First-seen source ASN for cookie auth	VPN logs enriched with ASN	Provider changes still produce “new infrastructure” patterns.
Cookie auth from endpoint not in fleet	Machine name, host ID, MDM or EDR inventory	Fake client identity often fails inventory correlation.
Cookie auth followed by new VPN address assignment	Auth logs, tunnel logs, DHCP or VPN pool logs	Captures successful progression into access.
VPN session followed by internal discovery	Firewall traffic, DNS, EDR, NDR	Detects post-auth behavior rather than exploit mechanics.
Cookie auth outside normal user schedule	Auth logs, HR or identity context	Useful for accounts with stable login patterns.
Certificate config drift	Config backups, firewall API exports, change management	Prevents the vulnerable condition from reappearing.

For Splunk-style environments, a starting search might look like this:

index=pan_logs sourcetype=pan:globalprotect
("GLOBALPROTECT" OR event_type="globalprotect")
(auth_method="Cookie" OR _raw="*Cookie*")
(action="login" OR subtype="gateway-auth")
(result="success" OR status="success")
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as src_ip values(machine_name) as machine_name values(client_os) as client_os values(gateway) as gateway by user
| sort - count

Then pivot into VPN session assignment:

index=pan_logs sourcetype=pan:globalprotect
("GLOBALPROTECT" OR event_type="globalprotect")
| eval is_cookie_auth=if(match(_raw,"Cookie") AND match(_raw,"success"),1,0)
| eval has_assigned_ip=if(match(_raw,"assigned") OR isnotnull(assigned_ip),1,0)
| stats max(is_cookie_auth) as cookie_auth max(has_assigned_ip) as assigned_ip values(src_ip) as src_ip values(assigned_ip) as vpn_ip values(machine_name) as machine_name by user, session_id
| where cookie_auth=1 AND assigned_ip=1

Field names will differ across deployments. The logic is more important than the exact syntax: find cookie-auth successes, correlate them with tunnel establishment, and then inspect what the assigned VPN identity did next.

What to do if logs show suspicious cookie authentication

Do not jump straight from “suspicious cookie auth” to “domain compromise.” Keep the investigation grounded.

A good triage sequence:

Step	Question	Evidence
1	Is the event from a known user, endpoint, and source network	Identity logs, VPN history, MDM, EDR
2	Was the username local admin, break-glass, service, or unexpected	Firewall account inventory, RBAC records
3	Was VPN IP assignment granted	GlobalProtect tunnel logs, VPN address pool logs
4	What routes were available to that session	Gateway config, user group mapping, security policies
5	Did the session touch internal systems	Firewall traffic logs, DNS, proxy, NDR, EDR
6	Did it attempt discovery or lateral movement	SMB, RDP, LDAP, Kerberos, WinRM, SSH, internal scanning
7	Was the device patched or mitigated at the time	Change records, config backups
8	Was the cookie certificate reused	Certificate inventory and firewall configuration

If VPN IP assignment occurred, treat the assigned VPN IP as a temporary investigation identity. Pull all traffic from that IP for the session window. Look for DNS queries, authentication attempts, port scans, access to domain controllers, access to internal admin interfaces, SaaS admin panels, file shares, CI/CD systems, secrets stores, and cloud control planes.

If cookie auth was accepted but no VPN IP was assigned, do not close the case immediately. Rapid7’s observation that 8 out of 10 impacted MDR customers had accepted forged cookie probes without a full VPN session means that partial signals may still represent real exploitation attempts. (Rapid7)

Hardening the GlobalProtect control plane

Patching closes the known vulnerability. Hardening reduces the next one.

Recommended controls:

Control area	Recommendation
Version management	Keep PAN-OS and GlobalProtect components on supported fixed releases. Track vendor advisories continuously.
Feature minimization	Disable Authentication Override if the usability benefit does not justify the risk.
Certificate hygiene	Use dedicated certificates for cookie encryption and decryption. Do not reuse them for HTTPS or unrelated features.
Exposure control	Restrict administrative interfaces to trusted networks. Avoid exposing management paths to the internet.
MFA	Keep MFA enabled, but do not treat it as a substitute for cookie integrity.
Cookie lifetime	Use short lifetimes for gateways protecting sensitive resources.
Logging	Retain GlobalProtect authentication and tunnel logs long enough to investigate delayed exploitation reports.
Detection	Alert on abnormal cookie authentication, especially local admin, new source ASN, new machine name, and VPN IP assignment.
Segmentation	Limit what a VPN user can reach after authentication. VPN access should not equal flat internal network access.
Retesting	After patching or mitigation, verify version, configuration, certificate use, and absence of new suspicious events.

Segmentation deserves emphasis. A VPN authentication bypass is much worse when a successful connection lands on a broad internal network. If VPN user groups are mapped to narrow access policies, the attacker’s next steps become harder and noisier. If VPN access lands near domain controllers, management interfaces, source code, file shares, and production admin tools, the same authentication bypass has a larger blast radius.

Related CVEs that show the same pattern

CVE-2026-0257 belongs to a broader class of edge and management-plane failures. The specific bug is about authentication override cookies, but the operational lesson is larger: exposed security infrastructure is also attack surface.

CVE	Why it is relevant	Exploitation condition	Risk	Fix or mitigation direction
CVE-2024-3400	Another PAN-OS GlobalProtect issue, but with command injection impact	Specific PAN-OS versions and feature configurations in GlobalProtect	Unauthenticated arbitrary code execution with root privileges on the firewall	Apply Palo Alto fixed versions and follow vendor workaround guidance
CVE-2024-0012	PAN-OS management web interface authentication bypass	Network access to the management web interface	Unauthenticated attacker can gain PAN-OS administrator privileges and tamper with configuration or chain with CVE-2024-9474	Restrict management access and apply fixed versions
CVE-2024-9474	PAN-OS privilege escalation chained with admin access	Requires PAN-OS administrator access to management web interface	Administrator can perform actions with root privileges	Apply fixed versions and protect the management interface
CVE-2026-0250	GlobalProtect app buffer overflow during portal and gateway exchanges	Man-in-the-middle attacker processing portal and gateway traffic	Disrupt processes and potentially execute code with SYSTEM privileges	Upgrade GlobalProtect app to fixed versions
CVE-2026-0257	GlobalProtect authentication bypass through authentication override cookie trust failure	GlobalProtect portal or gateway, authentication override cookies enabled, vulnerable certificate configuration	Unauthorized VPN connection	Upgrade, disable Authentication Override, or use a dedicated cookie certificate

Palo Alto Networks describes CVE-2024-3400 as a GlobalProtect command injection issue that may let an unauthenticated attacker execute arbitrary code with root privileges on the firewall. CVE-2024-0012 is an authentication bypass in the PAN-OS management web interface that can grant administrator privileges and enable further actions, including chaining with CVE-2024-9474. CVE-2024-9474 lets a PAN-OS administrator perform actions with root privileges. CVE-2026-0250 affects the GlobalProtect app and can be triggered during portal and gateway traffic processing by a man-in-the-middle attacker. (Palo Alto Networks Security)

The common thread is not that all these vulnerabilities work the same way. They do not. The common thread is that security infrastructure creates privileged pathways. VPN portals, gateways, management interfaces, identity features, and clients sit close to trust decisions. When they fail, they can fail with outsized impact.

Common mistakes during CVE-2026-0257 response

Mistake	Why it is risky	Better approach
Treating the issue as “only High” because of one score	NVD, Palo Alto, CISA, and Rapid7 context show urgent edge risk	Prioritize based on exposure, exploitation, and VPN impact.
Assuming MFA blocks the attack	The vulnerable path involves authentication override cookies	Patch or mitigate the cookie trust issue directly.
Checking only one gateway	Large environments may have regional, legacy, and test gateways	Inventory all GlobalProtect portals and gateways.
Upgrading without log review	Exploitation may have occurred before the upgrade	Preserve and review historical logs.
Relying only on published IOCs	Attackers can rotate infrastructure and hostnames	Build behavior-based detections.
Leaving certificate reuse undocumented	The same configuration problem can reappear later	Create a certificate-purpose inventory.
Running PoC checks without authorization	Exploit-style validation can create legal and operational risk	Use approved, scoped, logged validation only.
Ignoring unsupported PAN-OS	Unsupported versions may remain exposed with no safe patch path	Move to a supported fixed release.

A practical remediation checklist

Use this as an operational checklist, not a replacement for the Palo Alto Networks advisory.

CVE-2026-0257 response checklist

Asset inventory
[ ] List every GlobalProtect portal.
[ ] List every GlobalProtect gateway.
[ ] Identify PAN-OS or Prisma Access version for each.
[ ] Identify internet-facing endpoints.
[ ] Identify owners and change windows.

Configuration review
[ ] Check portal Generate cookie for authentication override.
[ ] Check portal Accept cookie for authentication override.
[ ] Check gateway Accept cookie for authentication override.
[ ] Identify Certificate to Encrypt/Decrypt Cookie.
[ ] Compare cookie certificate use against HTTPS and other services.

Mitigation
[ ] Upgrade to fixed PAN-OS or Prisma Access version.
[ ] If upgrade cannot happen immediately, disable Authentication Override.
[ ] If Authentication Override remains enabled, generate a dedicated cookie certificate.
[ ] Confirm users can re-authenticate after upgrade.
[ ] Confirm the old vulnerable configuration is not restored by template or Panorama push.

Detection and investigation
[ ] Export GlobalProtect auth logs from at least May 17, 2026 onward.
[ ] Search for Cookie authentication successes.
[ ] Search for local admin or unexpected usernames.
[ ] Search for unusual source IPs, ASNs, machine names, and MAC addresses.
[ ] Correlate suspicious events with VPN IP assignment.
[ ] Review internal activity from assigned VPN addresses.
[ ] Preserve evidence and document conclusions.

Post-fix validation
[ ] Confirm fixed version.
[ ] Confirm Authentication Override state.
[ ] Confirm dedicated certificate if feature remains enabled.
[ ] Confirm detection rules are active.
[ ] Retain response notes for audit and future incident review.

The strongest response is the one that leaves evidence behind. A team should be able to show what was affected, what was changed, when it changed, who approved it, which logs were reviewed, what suspicious events were found, and why the final status is considered fixed or mitigated.

FAQ

What is CVE-2026-0257?

• CVE-2026-0257 is an authentication bypass vulnerability in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS.
• Under vulnerable configuration conditions, a remote unauthenticated attacker can bypass security restrictions and establish an unauthorized VPN connection.
• The issue is tied to authentication override cookies and certificate configuration.
• Panorama and Cloud NGFW are not impacted according to Palo Alto Networks. (Palo Alto Networks Security)

Which products and versions are affected?

• Affected products include PAN-OS 12.1, 11.2, 11.1, and 10.2 below specific fixed releases.
• Certain Prisma Access 11.2 and 10.2 versions are also listed as affected.
• Cloud NGFW is listed as not affected.
• Unsupported PAN-OS versions should be upgraded to a supported fixed version.
• Administrators should use the Palo Alto Networks advisory as the final source for branch-specific upgrade targets. (Palo Alto Networks Security)

How do I know if my GlobalProtect deployment is exposed?

• Confirm whether the device runs an affected PAN-OS or Prisma Access version.
• Confirm whether GlobalProtect portal or gateway is configured.
• Check whether authentication override cookies are enabled on the portal or gateway.
• Review whether the authentication override cookie certificate is dedicated or reused with HTTPS or another feature.
• Review logs for suspicious cookie-based authentication, especially from unusual source IPs, local admin accounts, unfamiliar machine names, or suspicious MAC addresses. (Palo Alto Networks Security)

Does MFA stop CVE-2026-0257?

• MFA remains important, but it does not remove the need to patch or mitigate this vulnerability.
• Authentication override cookies are designed to reduce repeated authentication prompts after a successful login.
• If the vulnerable configuration accepts a forged authentication override cookie, the attacker may bypass the normal credential and MFA ceremony.
• Treat cookie integrity as part of the authentication boundary.

Should I patch first or disable Authentication Override first?

• If you can patch immediately, upgrade to the vendor-fixed release as the primary remediation.
• If patching requires a longer change window, disable Authentication Override as a temporary mitigation.
• If Authentication Override must remain enabled, use a dedicated certificate only for authentication override cookies.
• After patching, confirm users can re-authenticate and that the fixed behavior is in place. (Palo Alto Networks Security)

What logs should I review?

• Review GlobalProtect authentication logs and tunnel/session logs.
• Focus on successful Cookie authentication events, especially for local admin, privileged, or unusual accounts.
• Correlate suspicious cookie authentication with VPN IP assignment.
• Review downstream internal traffic from any assigned VPN IP tied to suspicious sessions.
• Enrich source IPs with ASN, geography, and historical login patterns.

Is a cookie authentication success without VPN IP assignment still important?

• Yes.
• Rapid7 reported cases where forged cookie authentication probes were accepted but no full VPN session was established.
• Such events may still indicate attempted exploitation or partial success.
• Investigate the event, source, username, endpoint identity, timing, and nearby activity before closing it.

Can I use a public proof of concept to test my firewall?

• Only within explicit authorization and a controlled scope.
• Rapid7 says a public proof-of-concept script exists, but exploit-style validation against production VPN infrastructure can create operational and legal risk.
• Safer first steps are version checks, configuration checks, certificate-use review, and log analysis.
• If exploit-style validation is necessary, obtain approval, notify operations, log the test, and preserve evidence.

CVE-2026-0257 is a reminder that authentication shortcuts are authentication systems. A cookie that lets a user skip another login prompt is not just a convenience feature. It is a trust artifact sitting at the VPN boundary.

The right response is not complicated, but it must be complete: identify affected GlobalProtect endpoints, patch or mitigate immediately, stop unsafe certificate reuse, review historical cookie authentication logs, investigate suspicious VPN access, and make the detection durable. The score matters less than the boundary. A bypass at the remote-access edge deserves edge-level urgency.