SonicWall Patched This VPN Bug—But If You Did Not Run Six Extra Manual Steps, Attackers Can Still Bypass Your MFA With 13 Brute Force Attempts and Reach a File Server in Under 30 Minutes

The Vulnerability Behind the Bypass

CVE-2024-12802 is a missing multifactor authentication enforcement bug in SonicWall's SSL-VPN appliances. The flaw is specifically about the UPN—User Principal Name—login format. When a SonicWall Gen6 appliance is configured against an LDAP backend, the standard username format is the sAMAccountName style: username. The UPN format, username@domain.com, is supposed to map to the same user account, with the same authentication policy applied.

On unpatched and incompletely patched Gen6 appliances, the UPN format takes a different code path. That code path forgets to invoke the MFA check. An attacker with a valid LDAP password can log in by entering the username in UPN format and bypass the second factor entirely. The password is the only thing standing between the attacker and the network behind the VPN.

SonicWall rated the bug 6.5 on the CVSS scale. The CISA Authorized Data Publisher disagrees—their assessment puts it at 9.1, the threshold for critical. The difference reflects how the two organizations weight the impact: SonicWall classifies an MFA bypass as a partial control failure; CISA classifies it as the loss of the primary control protecting a remote access perimeter.

Why the Patch Did Not Fix It

SonicWall released firmware patches for the Gen6 SSL-VPN line in early 2025. Most administrators installed them. That should have been the end of the story. According to the May 21 Help Net Security writeup and the underlying ReliaQuest threat spotlight, the firmware update alone is not enough.

Full remediation requires six additional manual steps inside the LDAP configuration page. They include enabling specific UPN suffix validation, updating the bind DN filter, and explicitly enforcing MFA for the LDAP authentication scheme rather than relying on the inherited policy. None of these steps are referenced in the firmware release notes. None of them happen automatically. If the administrator who installed the patch did not also walk through the LDAP reconfiguration, the appliance still appears patched, but the MFA bypass still works.

ReliaQuest's researchers observed the first in the wild exploitation of CVE-2024-12802 against operational environments between February and March 2026. The attackers were not finding zero day vulnerabilities. They were finding patched appliances whose owners had skipped the six manual steps. Across multiple incidents, the same pattern repeated: the appliance reported the latest firmware version; the LDAP configuration still routed UPN logins around MFA; the attacker walked in.

13 Attempts to a Working Credential

The attack workflow ReliaQuest documented is short. The attacker scans for exposed SonicWall SSL-VPN endpoints, identifies the LDAP domain in the certificate or login page metadata, and acquires a list of likely usernames. Common sources include LinkedIn scraping, prior credential leaks, and OSINT against the target's employee directory.

Once they have usernames, the attacker submits authentication requests using each username in UPN format with a small dictionary of common passwords. The MFA check does not fire. The login either succeeds, in which case the attacker has a working credential, or it fails, in which case they try the next combination.

ReliaQuest recorded one incident where the attacker reached a working credential after thirteen attempts. Thirteen. No prompt to the user. No SIEM alert tied to MFA failure, because MFA was never invoked. No anomalous IP block, because the source IP rotated across a residential proxy network. The login appeared as a normal successful authentication in the appliance's own logs.

From login to file server access measured under thirty minutes in the worst case ReliaQuest documented. The attacker enumerated internal hosts using the VPN tunnel, identified open SMB shares, and pulled documents. In several cases, ransomware was staged from the file server within an hour of initial login.

The Six Manual Steps Most Operators Missed

According to SonicWall's post incident advisory, the six configuration steps required to fully remediate are:

• Open the LDAP server configuration page in the SonicOS management UI
• Enable "Use TLS" and bind to LDAPS specifically, rejecting non TLS bind operations
• Update the bind distinguished name to use the validated DN format rather than the legacy sAMAccountName lookup
• Set the UPN suffix list explicitly, so that any login attempt using a UPN suffix not in the list is rejected
• Re-attach the MFA policy to the LDAP authentication scheme explicitly, replacing the inherited policy that contained the bypass
• Test the configuration with both sAMAccountName and UPN format logins to confirm MFA fires for both

The six steps are not technically complex. They are operationally fragile because they touch three different parts of the configuration: the LDAP server settings, the authentication scheme, and the MFA policy. In environments where those three areas are managed by three different teams—identity, security, and network—the patch can be installed by one team while the configuration changes never propagate to the others. The appliance reports patched. The configuration says exposed.

The Pattern: Patches That Are Not Complete

CVE-2024-12802 is not the first vulnerability where the public patch does not fully close the underlying flaw. Microsoft just patched a Word preview pane bug that requires registry changes to fully remediate, and most enterprise patch management systems do not deploy registry changes alongside the binary update. The same gap—a patch that "completes" but does not actually fix the bug—is recurring across the security industry in 2026.

The pattern matters because the entire enterprise patch management model assumes that installing the update is the end of the work. Tools like Microsoft SCCM, Tanium, and Ivanti report compliance based on installed versions. They do not generally verify that the post install configuration steps have been applied. The post install steps live in a vendor advisory that the security team has to read and translate into an internal runbook. That runbook then has to actually be executed by whoever owns the appliance.

For an attacker, the value proposition is obvious. Patched but misconfigured appliances are still vulnerable. The attacker does not need to find a zero day. They need a list of organizations running the affected product and a script that probes for the misconfiguration. The script for CVE-2024-12802 is exactly the brute force tool ReliaQuest documented. The list of organizations is whatever scan data the attacker has acquired.

What to Do Right Now

If your organization runs SonicWall Gen6 SSL-VPN appliances, the practical checklist is short:

• Confirm the firmware version is current—necessary but not sufficient
• Open the LDAP server configuration and validate all six manual steps have been applied
• Test a UPN format login with a service account whose MFA token you control, confirming the MFA prompt fires
• Review the VPN authentication logs for the past 120 days, filtering for UPN format usernames and looking for successful logins that did not have a corresponding MFA event in your MFA provider's logs
• If you find a gap between login events and MFA events, treat each gap as a possible compromise and investigate the post login activity from those sessions

The compromise indicators are not subtle once you know to look. Attackers who got in through CVE-2024-12802 in February and March 2026 typically moved laterally to file servers within hours and dropped ransomware or staged data exfiltration within a day. If your environment shows none of that activity, the bypass either was not used against you or was used but the attacker has not yet acted. Either way, the configuration fix is mandatory before the next attacker tries.

The Larger Defense Question

CVE-2024-12802 is also a reminder of what MFA is and is not. Multifactor authentication is a control that depends on its enforcement path. If the authentication endpoint does not invoke the MFA check, the second factor is not protecting anything. The user thinks they are protected because they enrolled in MFA. The login flow says they are protected because the MFA tile is visible in the admin console. The actual security boundary depends on whether the code path the attacker uses includes the MFA call.

A separate strain of MFA bypass attacks documented in 2026 hits the inbox rather than the VPN. OAuth consent phishing through Microsoft 365 device code flows compromised 340 tenants in five weeks without ever asking for a password. The victims completed MFA against the real Microsoft sign in page; the attacker captured the resulting token. The lesson is the same one CVE-2024-12802 teaches: MFA is a check at a specific point in a specific protocol. The attacker's job is to find the request path that does not include the check.

For defenders, the practical conclusion is that periodic verification of the MFA enforcement path matters as much as the MFA configuration itself. The configuration may say "MFA required." The actual login may not invoke it. The only way to know is to test the path with the same tooling an attacker would use, and to do it on a calendar, not after the breach.