Old Fortinet VPN Bug Is Back From The Dead — And Actively Getting Exploited
Fortinet has warned that a five-year-old FortiOS SSL VPN vulnerability, CVE-2020-12812, is being actively abused in the wild again under specific configurations. Attackers can quietly bypass two-factor authentication on FortiGate firewalls and walk straight into corporate networks.
In a new advisory, Fortinet says it is seeing “recent abuse” of CVE-2020-12812, an improper authentication bug in FortiOS SSL VPN that lets a user log in without being prompted for the second factor if they alter the username’s letter casing (for example, changing “Alice” to “alice”). The issue affects FortiOS SSL VPN when you have local users with 2FA tied back to LDAP, those same users also in LDAP groups, and at least one of those groups is used in an authentication policy for admin, SSL VPN, or IPsec VPN access.
To actually trigger the bug, the target FortiGate needs:
- Local user entries configured with 2FA that reference an LDAP server
- The same users as members of at least one LDAP group
- That LDAP group in use in an authentication policy (admin login, SSL VPN, or IPsec VPN)
In that setup, an attacker who knows or guesses a valid username and password can tweak the username’s case and potentially skip the second factor entirely, depending on the exact version and configuration. Fortinet originally patched this in supported FortiOS branches years ago, but a lot of appliances are either unpatched, misconfigured, or running with legacy setups that keep the door open. Security bulletins and third-party research today are flagging this as part of a broader wave of FortiGate 2FA-bypass attacks being leveraged for network intrusion, lateral movement, and data theft.
For developers and engineering leaders, this matters for a few uncomfortable reasons:
- VPN isn’t a magic moat: Your “secure perimeter” might be hanging off a niche bug in a device running old firmware and quirky LDAP mappings. If an attacker can bypass 2FA on the VPN, all your internal-only APIs, dashboards, and dev tools are effectively public.
- Auth logic is brittle in edge cases: This entire bug exists because of how username case and group mapping interact with 2FA. It’s a textbook reminder to treat identity flows as critical code, not just config — normalize inputs, be explicit about trust boundaries, and test weird edge conditions.
- Defense-in-depth is non‑negotiable: If your VPN is compromised and you’re still fine, it’s probably because you have strong internal auth, network segmentation, least-privilege roles, and audited access to things like CI/CD, artifact registries, and secrets stores. If you don’t, this is your nudge.
- Dependency management isn’t just libraries: Firewalls, VPNs, and IDPs are “infrastructure dependencies” with their own version sprawl and CVEs. They need the same disciplined patching and SBOM mindset you apply to app dependencies.
My take: treat this as a live-fire drill. Assume your VPN could be bypassed, then ask what an attacker would hit first: source code, CI, Kubernetes API, or your customer data. Lock those down, get your FortiOS boxes on fixed versions, tighten LDAP and 2FA configs, and stop assuming age equals safety — some of the most dangerous bugs are the ones we got bored of years ago.
