Harden PAN-OS by disabling auth override cookies
PAN-OS GlobalProtect authentication bypass exposure starts with a trust mistake. GlobalProtect can decrypt authentication override cookies with a configured private key, then accept the decrypted contents without checking a signature. If the same certificate is reused for HTTPS and override cookies, the public key can be pulled from the exposed service and used to build a forged cookie.
That turns a convenience feature into a VPN bypass. On affected PAN-OS GlobalProtect portal and gateway deployments, forged cookies can let an attacker authenticate as arbitrary users, including the local administrator account.
How the cookie path becomes a VPN bypass
GlobalProtect relies on the override cookie as a shortcut for access control. PAN-OS decrypts the cookie and trusts what comes out. That leaves a simple opening: if an attacker can produce a cookie that decrypts into a valid-looking identity, the gateway has little reason to push back.
The certificate setup is what makes the path practical. When the same certificate handles HTTPS and the override cookie flow, the public key sits where an attacker can recover it from the portal or gateway service. Once that key is available, cookie forgery stops being theoretical. The device is still doing the cryptographic work, just on attacker-controlled input.
Where GlobalProtect trusts decrypted cookie contents
The weak point is not the encryption step itself. It is the lack of signature verification after decryption. That matters because encryption alone does not prove who created the cookie. It only hides the contents.
If the portal or gateway accepts the decrypted result as valid authentication state, the control becomes fragile. A forged cookie does not need a real password prompt, a working MFA flow, or a live user session. It only needs the right shape and the right key material.
Why certificate reuse exposes the public key
Reusing the same certificate for HTTPS and override cookies creates a predictable leak. The public certificate is available from the public-facing service, which gives an attacker what they need to build a matching cookie.
That setup is bad enough on paper. In practice, it has been tied to active exploitation against unpatched devices. Some attempts only reached cookie acceptance, while others went on to create VPN sessions and internal access.
Turning off auth override without breaking access control
The clean fix is to remove the authentication override feature from the portal and gateway settings. If the cookie path does not exist, forged cookies stop being useful. That is the boring answer, and boring is what you want here.
If the override has to stay, do not reuse the same certificate for HTTPS and authentication override cookies. Use a separate certificate for the override function so the public key exposed by the web service is not the same key used in the cookie path. That keeps the public-facing certificate from doubling as a forgery aid.
This is a hardening issue, not a tuning one. Leaving the feature enabled because it is convenient is a poor trade when the device is already being targeted.
Remove the override feature from portal and gateway settings
Disable the override setting on both the GlobalProtect portal and gateway. If only one side is changed, the remaining entry point can still accept the same risky behaviour.
That change removes the bypass path rather than trying to watch it. There is no useful access control benefit in keeping a cookie mechanism that can be forged from exposed certificate material.
Use a separate certificate if the override must stay
A separate certificate keeps the override key material away from the public HTTPS service. That does not make the feature elegant, but it does reduce the chance that an attacker can recover what is needed for forgery from the public endpoint.
Treat certificate reuse as part of the vulnerability, not a harmless shortcut. If the same certificate is visible through the portal or gateway and also governs override cookies, the exposure is still there.
Checking the fix against live configuration
Verify the portal and gateway settings directly. Do not trust a change ticket, and do not trust a memory of having fixed it last month. The live configuration is what matters.
The useful check is simple: the portal and gateway should no longer accept forged cookies, and the device should not still expose the risky certificate setup. If the override feature remains active, the certificate arrangement needs a separate look. If the certificate arrangement remains unchanged, the override feature needs to go.
Confirm the portal and gateway no longer accept forged cookies
Test the live behaviour at the portal and gateway level. If forged authentication override cookies still work, the bypass is still open, whatever the config screen claims.
The failure mode here is obvious once it is in place: unauthorised VPN access without valid credentials. That is the part that matters, not the elegance of the exploit chain.
Verify the device is not still exposing the risky certificate setup
Check whether the public-facing HTTPS certificate is the same one used for override cookies. If it is, the public key exposure remains part of the attack path.
That check is worth doing even after the feature is disabled. Mixed certificate use tends to linger in old deployments, and old deployments are where this sort of thing keeps turning up.
