A CVSS 10 that hinged on one unchecked box: 'Validate Identity Provider Certificate'
CVE-2020-2021 let attackers bypass authentication on Palo Alto firewalls and VPNs using SAML, but only when one option was disabled: 'Validate Identity Provider Certificate.' A perfect-10 bug whose presence depended on a checkbox.
CVE-2020-2021 is a CVSS 10.0 authentication bypass in Palo Alto Networks PAN-OS, the kind of score reserved for the worst unauthenticated remote vulnerabilities. What’s unusual is the condition attached to it: it only applied when SAML authentication was enabled and the option “Validate Identity Provider Certificate” was disabled. With that box unchecked, PAN-OS didn’t properly verify the signature on SAML assertions, so an attacker could forge one and bypass authentication on whatever the SAML profile protected, GlobalProtect VPN, the management interface, Captive Portal, and more. A perfect-10 vulnerability whose existence on your device came down to a single configuration setting.
What the bug is
When PAN-OS uses SAML for authentication and certificate validation is turned off, improper verification of SAML responses lets an unauthenticated attacker with network access to the affected service impersonate a legitimate user and gain access. Palo Alto patched it in June 2020. The catch that made it widespread is that the vulnerable option was set in real deployments, sometimes because a SAML integration guide or identity provider’s setup steps called for disabling certificate validation to get things working. CISA flagged it for likely APT interest, and it carries the ransomware flag in the catalog. The asset matters: this is the firewall and VPN gateway, so an auth bypass is a path straight into the network it guards.
The lesson: “make it work” settings become “make it exploitable”
The interesting part of CVE-2020-2021 isn’t the cryptographic detail; it’s how the vulnerable configuration came to be common. Disabling certificate validation is a classic “just get the integration working” move. SAML and similar federation setups are fiddly, certificates expire and mismatch, and when an integration won’t authenticate, the fastest path to green is often to switch off the validation that’s failing. That unchecked box then quietly becomes the difference between a hardened device and a perfect-10 bypass.
The general principle: validation settings exist to be on. Any option labeled “validate,” “verify,” or “require,” for certificates, signatures, hostnames, issuers, is a security control, and turning it off to resolve an integration problem trades a setup headache for an exploitable gap. The right fix for a failing SAML integration is to fix the certificate trust, not to stop validating. Audit your federation and TLS configurations specifically for validation that’s been disabled, because those are the settings that turn into CVEs like this one.
What to do
- Patch PAN-OS to a version that fixes CVE-2020-2021 (the June 2020 releases and later). The patch corrects the validation behavior regardless of the setting, so it protects you even if the option is off.
- Enable “Validate Identity Provider Certificate” on every SAML authentication profile, and don’t disable it as an integration shortcut. If a SAML setup fails, fix the certificate trust between PAN-OS and your IdP rather than turning validation off.
- Audit for disabled validation across the board. Beyond this CVE, review your firewalls, VPNs, identity providers, and applications for any certificate/signature/issuer validation that’s been switched off, and turn it back on with the trust properly configured.
- Assume compromise if you ran the vulnerable config exposed. A SAML bypass on a VPN/firewall means potential unauthorized access; review authentication logs for sessions without legitimate logins, and rotate credentials and review access if you find signs of bypass.
- Keep the management interface off the internet, as with every perimeter-device management plane.
The reframe is to treat “validate” settings as non-negotiable and to be suspicious of any integration guidance that tells you to turn one off. CVE-2020-2021 was a perfect-10 vulnerability that many devices had only because someone disabled certificate validation to make SAML work, an entirely understandable shortcut that became a critical exposure. Patch PAN-OS, turn the validation back on, and fix integrations by fixing trust, not by removing checks. We flag the configuration-dependent entries because they’re the bugs you can sometimes close with a setting, and the ones a convenient shortcut quietly opened.
Sources
Share
Related field notes
-
The F5 auth bypass that fit in one header: Connection: X-F5-Auth-Token
CVE-2022-1388 let unauthenticated attackers run commands as root on F5 BIG-IP by abusing hop-by-hop header handling. Naming the auth-token header in the Connection header made the proxy strip it after the auth check read it, but before the backend did.
-
F5 CVE-2023-46747: the backend trusted a header that said 'I'm already an admin'
The Tomcat backend behind F5's config utility trusted a remote_user header as proof of authentication, assuming only the front-end could set it. HTTP-to-AJP request smuggling let attackers set it themselves, for unauthenticated root. Here's how to check, patch, and lock it down.
-
Patching the Fortinet auth bypass doesn't remove the admin account the attacker added
CVE-2022-40684 let unauthenticated attackers act as administrator on FortiOS, FortiProxy, and FortiSwitchManager by spoofing trusted headers. The exploit's payoff was planting an SSH key or super-admin account, so patching after exposure leaves the back door in place.
One email, every weekday morning.
You're in. Check your inbox.