Fortinet on Wednesday said it has observed “recent abuse” of a five-year-old FortiOS SSL VPN vulnerability being exploited in the wild, but only when specific configurations are in place.

The issue is tracked as CVE-2020-12812 (CVSS score: 5.2), an improper authentication flaw in FortiOS SSL VPN that allows a user to successfully authenticate without being challenged for the second authentication factor when the username is supplied with different letter casing.

“This happens when two-factor authentication is enabled in the ‘user local’ setting, and that user authentication type is set to a remote authentication method (eg, LDAP),” Fortinet noted in July 2020. “The issue exists because of inconsistent case-sensitive matching among the local and remote authentication.”

The vulnerability has since been actively exploited in the wild by multiple threat actors. The U.S. government has also categorized it as one of several vulnerabilities that were operationalized in 2021 campaigns focusing on perimeter security devices.

In a new advisory released December 24, 2025, Fortinet stated that successfully exploiting CVE-2020-12812 requires the following configuration:

• Local user objects on the FortiGate configured with 2FA and mapped back to LDAP
• The same user accounts must belong to a group on the LDAP server
• At least one LDAP group that includes those 2FA-enabled users must be configured on the FortiGate, and that group must be referenced in an authentication policy, for example for administrative access, SSL VPN, or IPSEC VPN

When these conditions are met, the flaw allows LDAP users configured with 2FA to bypass that control and authenticate directly against LDAP. This stems from FortiGate treating usernames as case-sensitive, while the LDAP directory evaluates them without case sensitivity.

“If the user logs in with ‘Jsmith’, or ‘jSmith’, or ‘JSmith’, or ‘jsmiTh’ or anything that is NOT an exact case match to ‘jsmith,’ the FortiGate will not match the login against the local user,” Fortinet explained. “This configuration causes FortiGate to consider other authentication options. The FortiGate will check through other configured firewall authentication policies.”

“After failing to match jsmith, FortiGate finds the secondary configured group ‘Auth-Group’, and from it the LDAP server, and provided the credentials are correct, authentication will be successful regardless of any settings within the local user policy (2FA and disabled accounts).”

From a SOC perspective, this means the vulnerability can allow administrative or VPN access without enforcing 2FA. Fortinet shipped FortiOS 6.0.10, 6.2.4, and 6.4.1 in July 2020 to modify this behavior. For environments that have not yet moved to these releases, Fortinet recommends running the following command on all local accounts to remove the authentication bypass condition:

set username-case-sensitivity disable

Customers running FortiOS versions 6.0.13, 6.2.10, 6.4.7, 7.0.1, or later are instructed to use the following command instead:

set username-sensitivity disable

“With username-sensitivity set to disabled, FortiGate will treat jsmith, JSmith, JSMITH, and all possible combinations as identical and therefore prevent failover to any other misconfigured LDAP group setting,” the company said.

As an additional hardening step, it is advisable to remove the secondary LDAP group if it is not operationally required. Doing so removes this attack vector entirely, as LDAP group-based authentication will no longer be possible in that path and logins will fail when the username does not match a local account.

That said, the updated guidance does not provide detail on the specific attack patterns observed in the field or clarify whether any of the attempts led to successful compromise. Fortinet further recommends that customers who identify evidence of admin or VPN logins occurring without 2FA enforcement contact Fortinet support and reset all associated credentials.