SonicWall CVE-2024-12802 is a reminder that an edge-device fix can fail if the required configuration step is missed. The CVE describes an SSL-VPN MFA bypass caused by separate handling of UPN and SAM account names in Microsoft Active Directory integrations. In practice, one login format may receive the expected MFA treatment while an alternate username format does not [1].
BleepingComputer reported on May 21, 2026 that attackers have abused this gap against Gen6 SonicWall firewalls, including environments where firmware had been updated but the manual LDAP reconfiguration step was not completed [2]. That distinction matters: the appliance can look patched while the exposed authentication path still exists.
Why this is dangerous
VPN appliances are high-value initial-access targets. A single valid account can put an attacker inside the network perimeter, and a login that bypasses MFA may not look like an exploit. It can look like a successful authentication event using a different username format.
For defenders, the important question is not only “is the firewall firmware current?” It is whether every AD-backed login path now enforces MFA consistently. UPN-style usernames and SAM-style usernames should be tested and logged as part of the fix validation.
What admins should verify
- Confirm the affected Gen6 SSL-VPN firmware is updated according to SonicWall’s advisory [3].
- Complete the LDAP/Active Directory configuration change, not only the firmware update.
- Test UPN and SAM account-name formats against MFA policy.
- Review recent VPN logins for unusual username formats, unexpected geolocation, and successful access without expected MFA challenge.
- Reset credentials and sessions for accounts that show suspicious VPN activity.
What to look for in logs
A successful bypass may not generate a clean “blocked attack” signal. Look for valid logins that used a different account-name form than the user normally uses, especially if the login came from a new ASN, residential proxy, VPS provider, or country. Also check whether VPN activity began shortly after a failed or unusual MFA event for the same identity.
Administrators should treat this as an exposed-perimeter check. If a VPN is internet-facing and depends on AD-backed MFA, patch status and identity-provider behavior need to be checked together. This is the same operational pattern seen in other edge-device incidents: remediation fails when the software update lands but the required configuration change does not.
