How a Capital Letter Bypasses Fortinet 2FA
Fortinet has warned administrators that real-world attacks are once again exploiting the vulnerability FG-IR-19-283 (CVE-2020-12812), first disclosed in July 2020. Under certain FortiGate configurations, the flaw allows attackers to bypass two-factor authentication and log in as if 2FA did not exist at all. The company has outlined the mechanics of the bypass and explained how to quickly determine whether a given configuration falls within the risk zone.
At the heart of the issue lies a subtle inconsistency: FortiGate treats usernames as case-sensitive by default, whereas LDAP directories do not. Because of this mismatch, the device may fail to recognize a user who enters their username with a different capitalization, prompting FortiGate to fall back on alternative authentication paths defined in access policies.
The vulnerable scenario arises when local FortiGate accounts with 2FA enabled are linked to LDAP, and LDAP groups are referenced in authentication policies—for example, for administrative access or SSL/IPsec VPNs. Everything hinges on a username that is “similar, but not identical.” If a user logs in as jsmith, FortiGate matches the local account and requests a second-factor token.
However, if the same user—or an attacker in possession of the password—logs in as Jsmith, jSmith, or any other capitalization variant that does not match the local account exactly, FortiGate fails to associate the login with the local user and instead switches to alternative methods, such as authentication via a separately configured LDAP group. With valid credentials, access is granted through LDAP, effectively ignoring local-user settings such as enforced 2FA or even a disabled account.
As a result, administrators or VPN users may authenticate without a second factor. Fortinet stresses that if there is any reason to believe this bypass has already been exploited, the system configuration should be considered compromised, and all credentials—particularly those used for LDAP or Active Directory integration—should be reset.
Mitigations for this behavior were introduced as early as 2020, with fixes included in FortiOS 6.0.10, 6.2.4, and 6.4.1. If upgrading to these or later versions is not possible, Fortinet recommends explicitly disabling case sensitivity for local usernames. In earlier branches, this is done by setting username-case-sensitivity to disable; in later releases (approximately FortiOS 6.0.13, 6.2.10, 6.4.7, 7.0.1, and newer), the parameter username-sensitivity should be set to disable. Once applied, FortiGate will treat jsmith, JSmith, and all capitalization variants as the same user, preventing fallback to alternative LDAP authentication triggered by case mismatches.
Fortinet also points to the practical root of the issue: the presence of a secondary LDAP group that takes over authentication when local-user verification fails. If such a group is not strictly required for business purposes, it should be removed from the configuration. And if LDAP groups are not used in authentication policies at all, the bypass path disappears entirely—any mismatch with a local account simply results in a denied login.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
