CVE-2024-12802 is the kind of edge-device flaw that can fool defenders twice: once during triage, and again during remediation. SonicWall and ReliaQuest both point to the same operational problem: on Gen6 SSL-VPN appliances, a firmware update alone does not fully remove the MFA bypass risk. If teams stop at patching and miss the required LDAP reconfiguration, an attacker with valid credentials can still reach the VPN without the MFA control defenders think is protecting it.
That changes the story from a routine vulnerability update into an active exposure-management problem. In the incidents ReliaQuest investigated between February and March 2026, attackers brute-forced credentials, bypassed MFA, moved into internal environments quickly, and in at least one case reached a file server within about 30 minutes. For teams running older SonicWall appliances, “patched” is not the same thing as protected.
What the flaw actually does
According to the NVD description and SonicWall's advisory, CVE-2024-12802 exists because SonicWall SSL-VPN handles UPN and SAM account-name formats separately when integrated with Active Directory. That means MFA can end up enforced for one login path but not the other.
In practice, an attacker with valid credentials can try the alternate account-name format and authenticate through the path where MFA is not effectively enforced. The result is an authentication bypass that looks uncomfortably normal from the defender side: the login can appear legitimate in logs even though MFA protection failed.
This is why the issue matters beyond a single CVSS label. It lowers an internet-facing VPN from strong authentication back toward a single-factor entry point, which is exactly the kind of opening ransomware-linked operators and initial access brokers look for.
Why Gen6 patching is not enough by itself
The most important operational detail is specific to Gen6 hardware. SonicWall says administrators must do more than install updated firmware. They also need to complete manual remediation steps around the LDAP configuration used by SSL-VPN.
Public reporting on the vendor guidance highlights the required sequence:
- delete the existing LDAP configuration that uses
userPrincipalNamein the qualified login field, - remove locally cached or listed LDAP users,
- remove the configured SSL-VPN user domain,
- reboot the firewall,
- recreate the LDAP configuration without the vulnerable
userPrincipalNamesetting, - and create a fresh backup so the unsafe LDAP configuration is not restored later.
That is the real defender trap. Patch dashboards may show the firmware as current, while the exploitable authentication path still exists. ReliaQuest describes exactly that condition in the environments it investigated: devices appeared remediated, but the manual steps had not been completed, so exploitation remained possible.
Gen7 and newer devices do not carry the same remediation caveat. SonicWall's public guidance indicates the firmware update alone is sufficient there. The incomplete-remediation problem is a Gen6 issue, which matters even more now that Gen6 SSL-VPN appliances reached end of life in April 2026.
What attackers were seen doing
ReliaQuest's write-up gives this issue defender value because it connects the vulnerability to concrete intrusion behavior rather than abstract risk language.
Across multiple environments, the researchers observed a consistent pattern:
- fast scripted brute-force attacks against VPN accounts,
- successful authentication that bypassed MFA,
- quick reconnaissance inside the internal network,
- testing of credential reuse on reachable systems,
- and deliberate logouts followed by later re-entry attempts in some cases.
In one escalation case, the attacker reportedly reached a domain-joined file server within roughly 30 minutes, used RDP with a shared local administrator password, and then attempted to deploy Cobalt Strike and a vulnerable driver associated with efforts to disable endpoint protection. The attempted command-and-control tooling and pre-ransomware sequence are exactly why this should be treated as more than a narrow VPN bug.
The behavior also fits a broader incident response concern: if the actor is gathering and reselling access, an apparently quiet VPN compromise can become someone else's ransomware incident later.
Why defenders can miss it
One of the more troubling details in the reporting is that the malicious login activity can still resemble a valid MFA flow in logs. That creates a dangerous false sense of control. Security teams may see successful VPN authentication and assume MFA is functioning as intended.
ReliaQuest points to sess="CLI" as a useful signal because it may reveal scripted or automated VPN authentication. The researchers also call out event IDs 238 and 1080, along with VPN logins from suspicious VPS or VPN infrastructure, as high-value indicators for review.
This matters because once the attacker is inside the VPN, the next step may be lateral movement, shared-local-admin abuse, or credential discovery on internal systems rather than noisy exploitation on the edge device itself.
What defenders should do now
1. Validate remediation, not just patch level
Do not treat current firmware alone as proof of safety on Gen6 appliances. Confirm that the LDAP-related remediation sequence was completed exactly as SonicWall specifies.
2. Hunt for the bypass pattern
Review SonicWall VPN logs for sess="CLI", event IDs 238 and 1080, unusual login timing, repeated credential attempts, and successful VPN sessions originating from infrastructure that does not fit normal user behavior.
3. Review account exposure around the VPN
Because this flaw still requires valid credentials, weak password hygiene and reused accounts increase the blast radius. Review privileged VPN access, shared local administrator usage, and whether the same identities can pivot directly into internal systems.
4. Assume exposed Gen6 devices need a retirement plan
Gen6 SonicWall SSL-VPN appliances are now end-of-life. Even if teams complete remediation, this is a strong signal to accelerate replacement with supported hardware and to revisit how internet-facing remote access is segmented and monitored.
5. Expand investigation beyond the firewall
If suspicious logins are found, investigate for downstream lateral movement, file-server access, RDP activity, credential reuse, and signs of attempted endpoint-defense tampering. The firewall may only be the first stage of the intrusion.
Strategic takeaway
CVE-2024-12802 stands out because it exposes a common weakness in enterprise remediation programs: teams often verify that a patch was installed, but not that the vulnerable condition was truly removed. On SonicWall Gen6 SSL-VPN, that gap is exploitable.
For defenders, the lesson is bigger than one vendor advisory. Internet-facing identity and remote-access controls need remediation workflows that validate real protection, not just version numbers. When a VPN appliance looks patched while MFA can still be bypassed, attackers get the exact kind of silent opening that leads to rapid internal access and potential ransomware staging.
The safest assumption is simple: if a Gen6 SonicWall SSL-VPN was only firmware-patched and never manually revalidated, treat it as potentially exposed until proven otherwise.
Frequently Asked Questions
What is CVE-2024-12802?
CVE-2024-12802 is an authentication bypass vulnerability in SonicWall SSL-VPN that can let an attacker bypass MFA in certain Active Directory-integrated configurations.
Why are Gen6 appliances the main concern?
Because SonicWall says Gen6 remediation requires manual LDAP reconfiguration steps after the firmware update. Without those steps, the MFA bypass risk can remain.
Is this being exploited in the wild?
ReliaQuest says it investigated multiple intrusions between February and March 2026 that it assesses with medium confidence as in-the-wild exploitation of CVE-2024-12802.
What should defenders do first?
Verify the Gen6 post-patch remediation steps, review VPN logs for sess="CLI" and related indicators, and investigate whether VPN accounts can pivot directly into internal systems.
