PAN-OS CVE-2026-0257: when GlobalProtect is patched and exploitable at the same time

The FCEB deadline for CVE-2026-0257 was yesterday. Federal civilian agencies in the United States had until 1 June 2026 to mitigate Palo Alto's GlobalProtect authentication bypass — a vulnerability disclosed on 13 May and added to the CISA Known Exploited Vulnerabilities catalog on 29 May. The advisory has been public for nearly three weeks. Rapid7 observed exploitation the day the advisory dropped + 4, and 8 of 10 of their MDR customers under attack had unauthorized VPN connections established before the activity was contained.

Here is the part the patch-and-forget audit checklist will miss: a fully patched PAN-OS firewall is still vulnerable to CVE-2026-0257 if the GlobalProtect portal reuses its TLS certificate for authentication override cookies. The fix is not the firmware version. The fix is a configuration choice the firmware version does not change.

What CVE-2026-0257 actually is

Palo Alto's advisory classifies the flaw as CWE-565 — reliance on cookies without validation and integrity checking. CVSS 4.0 score is 7.8 (HIGH). The vector is network, unauthenticated, no user interaction, low complexity.

The mechanism is mundane enough to be embarrassing. GlobalProtect supports an "authentication override" feature that issues a cookie after a successful login so the user does not re-authenticate on every connection. The cookie is encrypted and signed with a certificate. If the administrator picks a single certificate for "everything related to this portal" — TLS, SAML signing, cookie protection — the attacker can pull the public key from the public TLS endpoint, derive the signing parameters, and forge an authentication override cookie for any user, including the admin account.

There is no exploit-as-binary to detect on the wire. The attacker presents a forged cookie to a real GlobalProtect portal, and the portal validates the cookie against the certificate it trusts. The cookie checks out. The portal mints a VPN session. The attacker is inside.

Palo Alto's workaround tells the whole story:

Generate a new certificate exclusively for authentication override cookies and avoid reusing portal or gateway certificates.

That is the fix. Not the firmware update — the certificate split. The firmware update tightens cookie validation, but the misconfiguration that exposed the cryptographic material in the first place is not something a patch can address. It is a configuration decision encoded in panorama templates and pushed to thousands of devices.

The exploitation timeline

Date	Event
13 May 2026	Palo Alto publishes the advisory and PAN-OS hotfixes (12.1.7, 11.2.12, 11.1.15, 10.2.18)
17 May 2026	Rapid7 MDR observes first exploitation attempts
18 May 2026	First wave from Vultr-hosted IP: suspicious cookie auth against local admin accounts
21 May 2026	Second wave from Dromatics Systems range, same spoofed MAC aa:bb:cc:dd:ee:ff
29 May 2026	CISA adds CVE-2026-0257 to KEV; FCEB deadline set to 1 June 2026
1 June 2026	FCEB deadline; Help Net Security reports active exploitation continuing in the wild

Four days from public advisory to active exploitation. Twelve days from advisory to CISA escalation. Nineteen days from advisory to a federal-agency hard stop. None of that is unusual any more. What is unusual is that, on day 19, The Hacker News reporting confirms the attackers are still finding vulnerable instances — many of which run firmware versions that the vendor lists as patched.

Rapid7's IOCs are worth reading carefully because they tell you what the post-auth phase looks like, not just the cookie forge:

• Source IPs: 104.207.144.154, 146.19.216.119, 146.19.216.120, 146.19.216.125
• Machine names presented by the forged session: GP-CLIENT (Linux), DESKTOP-GP01 (Windows)
• Spoofed MAC consistent across both waves: aa:bb:cc:dd:ee:ff — a placeholder address, not a real OUI

The placeholder MAC is the smell test. A real GlobalProtect client never sends aa:bb:cc:dd:ee:ff as its hardware address. It is the kind of detail that a deep-packet inspection layer with a baseline of normal GlobalProtect client identifiers would catch on the first session. The cookie forge is invisible at the HTTP layer. The downstream client posture is not.

Why "patched" does not equal "safe"

The audit gap is structural. Most large enterprises run their compliance evidence on three signals:

1. Vulnerability scanner report — Nessus, Qualys, Rapid7 InsightVM. These check banner version and known CPE strings. PAN-OS 12.1.7 is patched against CVE-2026-0257 in the CPE database. Scanner marks PASS.
2. CMDB / patch management — confirms the firewall is on 12.1.7. Patch state = compliant.
3. Pen test or audit report — annual or quarterly. Last one passed.

All three of those will be green on a device that is fully exploitable, because none of them enumerate which certificate is bound to which TLS endpoint and whether the same certificate is also configured for cookie encryption on the auth-override path. That is a configuration property of the GlobalProtect portal, not a property of the PAN-OS binary.

The certificate-reuse condition exists in PAN-OS templates that have been pushed for years. Most environments only re-examine their certificate strategy when the cert expires. CVE-2026-0257 does not care about expiry. It cares about reuse.

Auditor: "Show me you patched CVE-2026-0257." CISO: "Here are the PAN-OS versions on every firewall. All on the fixed hotfix or later." Auditor: "Pass." Attacker: forges a cookie against a fully patched firewall

This is the gap. It is not specific to Palo Alto. It is specific to a class of CVEs — call them configuration-dependent CVEs — where the vendor's fix is correct, the firmware is updated, and the system remains exposed because the exploit surface is governed by a configuration choice the patch does not touch.

NSA-style "patch hygiene" metrics make this gap invisible. The dashboard says 100% patched. The truth is whatever the certificate templates say.

What conventional vulnerability scanners miss

A generic external scanner sees the GlobalProtect portal as one of three things: TLS certificate, banner version, observable behaviour. None of those will tell you about cookie-encryption-key reuse, because that key is never observable from outside. You can only enumerate the misconfiguration if you understand the vendor's authentication architecture and ask the device — or your management plane — which certificate is bound to which feature.

Most red-team toolchains will not do that automatically. ExploitDB ships a PoC tied to the bare exploitation primitive (forge cookie from public key). It will run if the certificate-reuse condition is present. It will not enumerate which of your portals have it present and which do not. That enumeration step — the one that turns a CVE PoC into a list of actually-vulnerable hosts in your estate — is the gap continuous validation has to fill.

For everything past the cookie forge, the visibility shifts from the firewall to the network. The forged session lands on the VPN-assigned IP. From the firewall's perspective it is a legitimate authenticated user. The next packets are reconnaissance: ARP, mDNS, port scans, SMB enumeration, attempts to reach the domain controller. Wire-side machine learning that has a baseline of how a real GlobalProtect user behaves catches the divergence — placeholder MAC, machine name pattern, scan velocity, time of day — before the attacker pivots. That is the second half of the defence and it is not solved by the firewall vendor's patch either.

What the regulator wants to see

NIS2 Title 13 (the technical and organisational measures), DORA's threat-led penetration testing RTS, NIST CSF 2.0, and ISO 27001 Annex A 8.8 (Management of technical vulnerabilities) all converge on the same shape of evidence:

• You can demonstrate continuous identification of known vulnerabilities across your estate.
• You can demonstrate that mitigations are effective, not merely applied.
• You can produce dated, signed, tamper-evident evidence of both.

A version list is the first. It is not the second or the third. Demonstrating that the mitigation is effective requires a control test — for CVE-2026-0257, that means actually attempting the cookie forge against the production portal and verifying the attempt fails. That is a quarterly red-team line item in most organisations. By the time the next quarterly pentest happens, the exploit will be 90 days into the wild and the dwell time on any compromise will run to weeks.

The auditor's question is not "are you patched?" It is "show me what you tested, when you tested it, and that the evidence cannot have been edited after the fact." A configuration-dependent CVE breaks the first answer if the second is missing.

Closing the audit gap

The 32 frameworks Zero Hunt continuously maps every finding against — NIS2 Title 13, DORA TLPT RTS 2025, ISO 27001 Annex A 8.8 and 8.9, NIST CSF 2.0 ID.RA-01 and PR.IR-04, PCI-DSS 11.4.x, SOC 2 CC7.1 — all share a control text that maps cleanly to "configuration tested, evidence dated". The cross-framework mapping turns a single GlobalProtect cookie-forge test into evidence against eight controls at once, not a single line item in a single audit.

The Generative Pentest pillar then handles the part the scanner cannot: the 10-agent AI swarm enumerates the certificate binding state per portal, instantiates the forge attempt in an ephemeral Docker container against a non-production GlobalProtect surface, and records the result as a signed finding. Continuous, change-triggered: when a new certificate is pushed to a portal via Panorama, the next campaign tests the new configuration within the hour, not the next quarter. Every finding is ECDSA-signed at write time — the evidence the regulator wants is generated as a by-product of the test, not assembled retroactively in a Word document the week before the audit.

The defence in front of the cookie forge — wire-side detection of the post-auth divergence — is the AI Traffic Analysis pillar's 4-head inference model running locally on the appliance GPU at multi-gigabit line rate. The placeholder MAC, the GP-CLIENT machine name pattern, the scan velocity from a freshly assigned VPN IP — those are the signals the model is trained to catch on the wire while the session is alive, not in tomorrow's SIEM digest.

The combination is the audit answer:

• What did you test, when? Continuous, change-triggered, per-portal certificate-binding enumeration plus forge attempt.
• Did the mitigation work? Signed pass/fail per portal, dated.
• Can you prove the evidence is intact? ECDSA chain of custody from finding write to Trust Center export.
• What detects the gap if it slips through? Wire-side ML on the post-VPN-auth session.

CVE-2026-0257 is not the last configuration-dependent CVE. Edge VPN appliances are full of them, and the next one is already in someone's bug bounty queue. The right answer is to stop treating "patched" as a synonym for "safe", and to wire the evidence chain that proves which one your estate actually is.

For more on how the continuous-evidence model fits a NIS2 first audit, see the known-CVE gap most audits will hit by 30 June. For the pillar-2 detection pattern when the attacker is already past the perimeter, see the 858-day dwell time at UNMC REDCap.