A FortiGate flaw first fixed in 2020 is still helping attackers get around two-factor authentication in certain LDAP setups. Known as CVE-2020-12812, the bug takes advantage of a mismatch in how FortiOS and directory services read uppercase and lowercase letters in usernames. With valid login details and the right firewall configuration, an attacker may avoid the second-factor prompt and gain access to a VPN or FortiGate administrative account.
Why This Old FortiGate Flaw Lingers
CVE-2020-12812 is an authentication flaw found in certain FortiOS setups that use LDAP accounts and two-factor authentication. Fortinet disclosed and fixed the problem in July 2020. That sounds like old news, but the threat did not simply fade away.
On December 24, 2025, Fortinet reported that attackers had recently used the vulnerability in real attacks. In other words, a five-year-old flaw was still working against organizations that had not fully patched or corrected their systems.
Why would a known flaw survive for so long? Firewalls often stay in service for many years. Updating them can be stressful because a failed upgrade might interrupt remote work, business services, or access to important systems. Some teams delay updates for months. Others inherit older devices with unclear records.
Authentication rules also tend to grow messy over time. A company adds new users, creates another VPN group, changes an administrator role, or connects a local account to Active Directory. Each change may seem harmless. Together, they can create more than one login path for the same person.
The flaw centers on a small difference in how systems read usernames. In the affected setups, FortiGate treats usernames as case-sensitive. Many LDAP directories, including Microsoft Active Directory, usually do not.
That means Active Directory may see “jsmith,” “JSmith,” and “JSMITH” as the same user. An affected FortiGate may not.
A simple case change can cause FortiGate to miss the local user account that requires a security token. It may then try an LDAP group policy that accepts the same password without asking for the second factor.
The National Vulnerability Database entry for CVE-2020-12812 confirms that changing the case of a username may allow a user to sign in to an affected FortiOS SSL VPN without providing the expected second factor.
Which FortiGate Setups Are Exposed
Not every FortiGate device that uses LDAP, Active Directory, or FortiToken is open to this bypass. Several conditions must exist at the same time.
First, the FortiGate must have a local user account with 2FA enabled. That local user must also point to an account on an LDAP server.
Second, the same person must belong to one or more groups in the LDAP directory.
Third, at least one of those LDAP groups must be added to the FortiGate and used in an authentication policy.
That policy might control access to:
- An SSL VPN portal.
- An IPsec VPN connection.
- A FortiGate administrator page.
- Another service protected by FortiGate login rules.
The main problem is overlap. The same user can reach the same resource through two different paths, but only one path requires the second factor.
Imagine that a FortiGate has a local user called “jsmith.” The account checks the password through Active Directory and also requires a FortiToken code. The same employee belongs to an Active Directory group called “Remote Employees,” which has permission to use the SSL VPN.
When the person signs in as “jsmith,” FortiGate finds the local account and asks for the token. Good. That is what should happen.
But what if the username is entered as “JSmith”?
On an affected system, FortiGate may not match “JSmith” to the local account because the capital letters are different. It then checks another allowed login path. Active Directory sees “JSmith” as the same user, accepts the password, and may let the person in through the LDAP group without asking for the token.
LDAP itself is not the weakness. The danger comes from two authentication paths that do not apply the same security rules.
Fortinet’s FG-IR-19-283 security advisory lists the affected FortiOS versions and explains the configuration conditions that allow this MFA bypass to occur.
How the Username Trick Bypasses 2FA
There is no complicated hacking tool behind this method. No special file. No memory attack. The attacker only changes one or more letters in a valid username from lowercase to uppercase, or the other way around.
That does not mean anyone can walk in without a password. The attacker still needs valid LDAP login details for an affected account.
Those credentials might come from a phishing email, a stolen browser password, credential-stealing malware, password reuse, an earlier data breach, or another criminal who already gained access. Once the attacker has a working username and password, trying a few case changes takes little effort.
Here is how the bypass may happen:
- The attacker enters a valid LDAP username and password.
- The attacker changes the case of one or more letters in the username.
- FortiGate fails to match that version to the local 2FA account.
- The firewall checks another allowed LDAP group or policy.
- LDAP recognizes the changed username as the real account.
- The directory accepts the correct password.
- FortiGate grants access without showing the usual second-factor prompt.
This is best viewed as a login-routing problem. Two-factor authentication is active, but only on one route. A second route leads to the same place with weaker protection.
That is why checking a box that says “2FA enabled” is not enough. Administrators need to test every way a user can reach the VPN or management page. The result should always be the same.
Fortinet’s December 2025 report on observed abuse confirms that attackers used the flaw in environments where local 2FA accounts overlapped with LDAP groups used in authentication policies.
What Attackers Can Do After Login
The harm depends on what the weaker login policy protects. A successful bypass might open an SSL VPN, an IPsec VPN, a FortiGate management page, or another protected service.
VPN access is especially useful to attackers because it places them inside a trusted remote connection. From there, they may reach systems that are hidden from the public internet.
These could include file servers, internal websites, employee computers, remote desktop services, backup systems, identity servers, and management consoles.
Administrative access can be even worse. Depending on the account’s rights, an attacker may be able to change firewall rules, create users, edit VPN settings, view configurations, weaken logging, or leave behind another way to get in later.
Possible results include:
- Unauthorized access through a real user account.
- Movement from the VPN into other parts of the network.
- Theft of files, passwords, or private company data.
- Creation of hidden accounts or extra VPN access.
- Changes to firewall and authentication rules.
- Damage to logging or security monitoring.
- Ransomware or other malware inside the network.
This type of login may not look dramatic in the logs. The password is valid. LDAP approves the account. The session may seem normal at first glance.
That is part of the danger.
A security team that searches only for failed logins or obvious exploit traffic may overlook a successful LDAP session that never produced the expected 2FA event.
CISA has added CVE-2020-12812 to its Known Exploited Vulnerabilities Catalog, which tracks flaws backed by evidence of real-world attacks.
How to Fix the FortiGate 2FA Flaw
Start with an inventory. Every FortiGate appliance should be identified, including devices at branch offices, test sites, remote facilities, and locations managed by outside vendors.
Then confirm the exact FortiOS version running on each device. Do not rely on an old spreadsheet or a note from the last administrator. Check the appliance itself.
Fortinet first added support to prevent this behavior in FortiOS 6.0.10, 6.2.4, and 6.4.1. Those are historical fix points, not ideal versions to install today. Organizations should move to a FortiOS release that is still supported and approved for their hardware.
Fortinet also published settings that turn off username case sensitivity. The command varies by FortiOS version. Some corrected releases use set username-case-sensitivity disable, while later versions use set username-sensitivity disable.
Do not paste commands into a production firewall without checking the correct documentation for that version. Test the change first. A rushed firewall edit can create a different problem.
A solid repair process should include these steps:
- List every FortiGate device and its FortiOS version.
- Upgrade outdated or unsupported firmware.
- Review local users connected to LDAP.
- Find every local account with 2FA enabled.
- Check which LDAP groups appear in VPN and admin policies.
- Look for users who can enter through more than one policy.
- Remove group access that is no longer needed.
- Require the same second factor on every valid login path.
- Limit administrative pages to trusted management networks.
- Test normal, mixed-case, failed, and successful logins.
- Save the corrected setup as the approved baseline.
Patching the software is important, but it is only part of the job. A confusing set of overlapping policies can still create weak access rules, even when this exact bug has been fixed.
The Fortinet PSIRT mitigation details provide the affected-version list, original fixed releases, and vendor-approved case-sensitivity settings.
What the Logs May Show
Finding the vulnerable setup does not prove that someone used it. Still, the organization should check.
Fortinet recommends reviewing authentication logs for unusual changes in username capitalization. Investigators should compare LDAP logins with local user activity and 2FA records.
For example, a login by “JSmith” may stand out when that user normally appears as “jsmith.” A successful LDAP session with no matching token event deserves a closer look.
Evidence may appear in several places:
- FortiGate event and VPN logs.
- Administrator login records.
- Active Directory or LDAP logs.
- Identity and multifactor authentication records.
- Endpoint security alerts.
- DNS, proxy, and network traffic logs.
- File server and remote desktop activity.
- User, group, VPN, and firewall changes.
Investigators should also watch for unfamiliar IP addresses, odd login times, strange locations, new user accounts, large file transfers, disabled security tools, or movement between internal systems after the login.
One clue may mean very little on its own. Several clues lined up in time can tell a different story.
If the bypass was used, or if the evidence strongly suggests it was used, the event should be treated as a real compromise. That may require password resets, token replacement, session removal, policy reviews, and checks across other systems the attacker could have reached.
CISA’s StopRansomware Guide explains how stolen credentials and remote access can lead to wider network compromise and provides practical steps for prevention and response.
Why Configuration Drift Adds Risk
Firewalls rarely stay as simple as they were on installation day.
A company adds a new department. Contractors need temporary VPN access. An old portal stays online during a migration. Someone creates a broad LDAP group to solve an urgent access problem. Later, nobody remembers why the rule was added.
This is configuration drift.
Each change may seem reasonable at the time. Months or years later, several rules may give one user access to the same service through different routes. One route requires 2FA. Another asks only for a password.
Everything may still look healthy. The VPN connects. The firewall dashboard shows 2FA. Routine checks pass.
But the protection is weaker than it appears.
Good configuration management means keeping a clear record of expected users, groups, VPN portals, administrator roles, login methods, and policies. Changes should be reviewed for how they affect the whole login process, not just one rule.
A useful question is simple: Can this user reach the same resource through another policy with weaker authentication?
When nobody can answer with confidence, the setup needs an audit.
The NIST SP 800-128 configuration management publication explains how organizations can build, maintain, and watch security baselines so that unwanted changes do not quietly increase risk.
How JENI® Supports Stable Endpoints
JENI® does not update FortiGate appliances, inspect FortiOS policies, manage LDAP accounts, detect CVE-2020-12812, or replace a trained security team.
It has another role.
JENI® helps maintain and repair supported Windows and macOS computers by using native operating-system tools. It can address damaged system components, temporary file buildup, network-stack trouble, and other common reliability problems.
Stable computers support better security work. VPN clients, browsers, update services, log tools, endpoint protection, and management software all depend on the operating system beneath them.
When that base is damaged or unstable, useful tools may fail, freeze, produce errors, or behave in ways that are hard to predict.
JENI® can help users:
- Run supported native system repair tools.
- Remove unneeded temporary files and clutter.
- Reset selected network components when connections fail.
- Create local reports for completed maintenance tasks.
- Maintain computers without advertising or background telemetry from JENI Systems.
JENI® is a system maintenance and repair utility. It is not a FortiGate scanner or an incident-response platform.
A stable endpoint can help security software work as intended. It cannot fix an outdated firewall, recover stolen LDAP credentials, or correct a FortiGate policy that allows a second-factor bypass.
FortiGate 2FA Bypass FAQ
Can the bypass work without a password?
No. The attacker generally needs valid LDAP login details for an account affected by the setup. The flaw can avoid the second factor, but it does not remove the main password check.
Is CVE-2020-12812 a zero-day?
No. Fortinet disclosed and fixed the vulnerability in July 2020. It drew fresh attention after Fortinet confirmed new abuse in the wild on December 24, 2025.
Does FortiToken stop the bypass?
Not in every affected setup. FortiToken may protect the local account while a separate LDAP group lets the same user reach the VPN or management page without the token.
Are patched FortiGate devices protected?
Supported FortiOS versions include changes that prevent this specific username case issue when they are set up correctly. Administrators should still check firmware, remove policy overlap, and test every valid login route.
How can a company find past abuse?
Teams should compare FortiGate, VPN, LDAP, 2FA, endpoint, and network records. Mixed-case usernames, successful LDAP logins without token events, unknown IP addresses, policy changes, or unusual internal activity may point to misuse.
Make Authentication Fail Closed
CVE-2020-12812 is troubling because the trick is so small. An attacker with valid credentials may only need to change a letter from lowercase to uppercase to reach a weaker login path.
The larger lesson goes beyond FortiGate. Multifactor authentication is not effective just because a dashboard says it is turned on. It must protect every path to the same resource.
Organizations should keep FortiOS supported, remove unneeded policy overlap, standardize how usernames are matched, limit administrative access, and review old logs for signs of abuse.
The system should also fail closed. When it cannot match a user to the correct account and security policy, it should deny access. It should not move on to an easier option.
The official CVE-2020-12812 record describes how affected FortiOS SSL VPN setups may allow access without the second factor when the case of the username is changed.
An old vulnerability can still create a fresh breach. The date on the patch matters less than the work that followed it. Every exposed device must be updated. Every risky rule must be corrected. And when the logs look strange, someone needs to investigate.
Related Articles
Learn why attackers target VPN accounts, how stolen credentials lead to network access, and which defenses help prevent remote access attacks.
How Phishing Bypasses Weak MFA
See how modern phishing kits defeat older MFA methods, steal active sessions, and make phishing-resistant authentication increasingly important.
Security Logging for Small IT Teams
Learn how smaller IT teams can collect useful security logs, detect suspicious access, and create practical alerts without running a full SOC.
WatchGuard Firebox Flaw Explained
Explore how a serious firewall vulnerability can expose remote networks, why timely patching matters, and what administrators should review.
