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
| क्षेत्र | Current public information |
|---|---|
| सीवीई | CVE-2026-0257 |
| Vendor | Palo Alto Networks |
| Affected area | GlobalProtect portal and gateway in PAN-OS, and certain Prisma Access versions |
| संवेदनशीलता वर्ग | 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 |
| व्यावहारिक प्रभाव | 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 | यह क्यों मायने रखती है |
|---|---|
| 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. (रैपिड7)
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. (रैपिड7)
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 या 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. (रैपिड7)
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. (रैपिड7)
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 | प्रभावित संस्करण | 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 | यह क्यों मायने रखती है | 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. (रैपिड7)
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. (रैपिड7)
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. (रैपिड7)
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. (रैपिड7)
Look for patterns like these:
| Signal | यह क्यों मायने रखती है | 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 | क्रियाएँ | 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 |
| चल रहे | 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:
| निवारण | 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:
- Disable Authentication Override on exposed GlobalProtect endpoints if the upgrade cannot be completed quickly.
- Upgrade to the fixed release.
- Reconfigure Authentication Override only if the user-experience need remains.
- Use a dedicated cookie certificate.
- Validate that portal and gateway behavior matches the intended design.
- 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. |
| निगरानी | 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. (रैपिड7)
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 | कम |
| Configuration check | Authentication override cookies are enabled or disabled | कम |
| Certificate-use review | The cookie certificate is dedicated or reused | Low to medium |
| Log review | Suspicious cookie auth did or did not occur | कम |
| Lab reproduction | The exploit mechanism works in a controlled lab | मध्यम |
| 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. (पेनलिजेंट)
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:
| कदम | Question | प्रमाण |
|---|---|---|
| 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. (रैपिड7)
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. |
| पहचान | 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. |
| पुनः परीक्षण | 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.
| सीवीई | 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.
अक्सर पूछे जाने वाले प्रश्न
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
Cookieauthentication 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.

