How a VPN Authentication Override Cookie Works and Why a Forged One Is a Full Login

Most VPN gateways offer a way to stop prompting users for a password every time a laptop wakes up or changes networks. Palo Alto Networks calls its version an authentication override cookie. Cisco, Fortinet and others have equivalents under different names. The mechanism is convenient, widely enabled, and poorly understood by the people who switch it on. The ransomware campaigns exploiting CVE-2026-0257 in GlobalProtect, covered in our news report on Settra and Qilin, are a case study in what happens when the cookie that replaces a login is not as well protected as the login it replaces.

The problem the cookie solves

A remote-access VPN authenticates a user at connection time. In a typical GlobalProtect deployment the client first contacts the portal, which authenticates the user and hands down configuration, then contacts a gateway, which authenticates the user again and establishes the tunnel. Each of those steps can involve a password, a one-time code, a certificate check or a SAML redirect to an identity provider.

Mobile users reconnect constantly. A laptop that moves from office Wi-Fi to a hotspot to a hotel network may re-establish its tunnel several times an hour. Prompting for credentials and a second factor on every reconnect is unworkable, so the gateway needs a way to say "I already checked this person recently" without asking again.

The authentication override cookie is that memory. After a successful authentication, the portal or gateway generates a cookie, encrypts it, and sends it to the client. The client stores it and presents it on subsequent connections for a configurable lifetime. If the appliance accepts the cookie, the user is in. No password, no second factor, no identity provider round trip.

Why the cookie is a bearer token

Security engineers have a precise name for a credential that grants access to whoever presents it: a bearer token. An OAuth access token is a bearer token. A session cookie on a web application is a bearer token. The GlobalProtect authentication override cookie is one too. The gateway does not re-verify that the person holding the cookie is the person who originally authenticated. It verifies the cookie.

That means the security of the whole remote-access path, for the lifetime of the cookie, rests on two properties:

• Confidentiality. Nobody else should be able to read or obtain a valid cookie.
• Integrity. Nobody should be able to construct a cookie the gateway will accept without having authenticated first.

Confidentiality failures are the familiar ones: an infostealer lifts the cookie file from a compromised laptop, or a stolen device yields it from disk. Integrity failures are rarer and far more dangerous, because they do not require any victim at all. If an attacker can mint a cookie the appliance treats as genuine, every account becomes reachable from the internet with no credential theft, no phishing and no second-factor prompt.

CVE-2026-0257 is an integrity failure. Its weakness classification is CWE-565, reliance on cookies without validation and integrity checking. Palo Alto Networks' fix adds strict HMAC validation to the cookie, which tells you what was missing: a keyed message authentication code that lets the gateway prove the cookie was produced by the appliance and has not been altered. Without that proof, the appliance was trusting the contents of a cookie it could not authenticate.

Where the certificate comes in

Encryption alone does not give you integrity. An encrypted blob that decrypts to plausible-looking fields will be accepted unless something separately verifies that the blob is authentic. In GlobalProtect's design, the cookie is tied to a certificate that the administrator selects when enabling the feature.

The advisory for CVE-2026-0257 makes the certificate the centre of its workaround: generate a certificate used exclusively for authentication override cookies, store it securely, and never reuse the portal or gateway certificate for this purpose. Palo Alto Networks adds that a certificate previously used for other functions must be replaced with a dedicated one.

The vendor does not publish the forgery details, and we will not speculate about the exact mechanics. The design lesson is clear enough on its own. A certificate that also serves TLS for the portal is, by definition, a certificate whose public half the whole internet has seen, and whose private half lives in more places and more configuration paths than a single-purpose key. Any cryptographic construction that protects a bearer token should depend on key material that exists for that purpose and nothing else. The same principle is why a well-run OAuth deployment signs tokens with a key that is not also its web server certificate.

What a forged cookie looks like on the wire

From the appliance's point of view, a forged cookie is indistinguishable from a legitimate reconnect. Rapid7's analysis of exploited GlobalProtect appliances shows successful gateway-auth and login events in the GlobalProtect log with the authentication method recorded as "Cookie", followed by the ordinary client requests to the HIP report and configuration endpoints. The username field contains a real account, often a local administrator. The source address is a hosting provider rather than a residential ISP, and the client hostname is whatever the attacker's tooling claims: GP-CLIENT, DESKTOP-GP01, or simply kali.

That is why this class of bug is so valuable to ransomware operators. A credential-stuffing attack generates failed logins. A phishing campaign leaves email artefacts. A forged bearer token generates one successful login and then disappears into the noise of normal remote work. How to Hunt VPN Logs for Sessions That Never Entered a Password covers the signals that do remain.

Designing the feature safely

If you run GlobalProtect or any VPN with an equivalent feature, four decisions determine your exposure.

Decide whether you need it at all. Authentication override exists to reduce prompts. If your clients already use certificate-based authentication, or your identity provider issues long-lived sessions that the VPN can rely on, the cookie may add nothing but risk. Palo Alto Networks lists disabling it as a legitimate mitigation.

Give it a dedicated certificate. Follow the vendor's guidance and never share key material between the cookie and any other function. Put the certificate's expiry and rotation on the same calendar as your other secrets.

Keep the lifetime short. A cookie valid for days is a bearer token valid for days. Set the override lifetime to the shortest interval your users will tolerate, and remember that a forged cookie's usefulness scales with the same number.

Plan for revocation. Because the cookie is a bearer token, the only way to invalidate one you did not issue is to invalidate all of them. The fix for CVE-2026-0257 forces every user to re-authenticate once after upgrade precisely so the appliance can reissue cookies under the new validation scheme. Terminating all sessions after a patch is not an overreaction; it is the only way to be sure. Why Patching Your VPN Gateway Does Not Evict the Attacker Already Inside explains why that step belongs in every perimeter remediation runbook.

The general lesson

Every "remember me" feature on a perimeter device turns a strong authentication into a stored artefact that stands in for it. The artefact inherits the full privilege of the original login and none of its friction. Treat it as you would any other secret of that power: single-purpose key material, short lifetimes, integrity protection you can verify, and a tested way to revoke everything at once. CVE-2026-0257 is what it looks like when one of those four is missing.