It’s a side door that only opens if the badge reader is wired to two employee names instead of one identity
CVE-2024-12802 is an SSL-VPN MFA bypass in SonicWall SonicOS when SSLVPN is tied to Microsoft Active Directory and the appliance treats UPN and SAM logon formats as separate authentication paths. The published affected ranges are Gen6 NSv 6.5.4.4-44v-21-2457 and older, Gen6 hardware 6.5.4.15-117n and older, Gen7 NSv 7.0.1-5161 and older, Gen7 hardware 7.1.1-7058 and older, 7.1.2-7019, and TZ80 8.0.0-8035; fixed trains reported by advisory mirrors are 6.5.4.4-44v-21-2472, 6.5.5.1-6n, 7.0.1-5165, 7.1.3-7015, and 8.0.0-8037.
The raw 9.1 story overstates reality for most enterprises because this is not a clean unauthenticated pre-auth break in practice: the attacker still needs an exposed SSLVPN, AD-backed auth, the vulnerable UPN/SAM handling, and a working credential or a sprayable account. But downgrading it too far is also wrong, because on internet-facing Gen6 devices the gap between 'patched firmware' and 'actually remediated' is operationally dangerous, and ReliaQuest reported first known in-the-wild exploitation between February and March 2026 on devices that looked patched in dashboards.
4 steps from start to impact.
Find an exposed SonicWall SSLVPN edge
- SSLVPN is enabled and externally reachable
- The appliance is in an affected SonicOS branch
- The deployment uses Microsoft AD/LDAP for SSLVPN auth
- Many enterprises no longer expose SSLVPN broadly, or restrict it behind geofencing / allowlists
- Gen7+ devices are fully remediated by firmware alone according to ReliaQuest; the sticky problem is mostly Gen6
- Deployments not using AD-backed SSLVPN are out of scope
Spray credentials through the alternate login path
sess="CLI", consistent with a command-line VPN auth tool, followed by successful login through the unprotected account-name format. The bypass works because MFA is enforced per login string format rather than consistently per user identity, so a user protected on DOMAIN\\user may still be reachable via user@domain if that path is left unprotected.- The attacker has valid credentials or can brute-force a weak account
- UPN/SAM handling is misaligned in the SSLVPN+AD configuration
- For Gen6, the six post-patch LDAP remediation steps were not completed
- This is the decisive brake on severity: a credential is still required in practice
- Strong lockout policy, password hygiene, and source-IP restrictions break most opportunistic spraying
- If the environment does not authorize UPN-style logins or lacks an extra AD UPN suffix, reachability drops
sess="CLI" plus Event ID 238 failed VPN logins and Event ID 1080 successful SSLVPN zone logins. Most vuln scanners will miss active bypass state entirely.Land a trusted VPN session inside the network
- The compromised VPN account has meaningful network access
- Internal segmentation allows VPN clients to reach server tiers
- Credential reuse or shared admin credentials exist internally
- Well-segmented VPN zones sharply limit blast radius
- ZTNA-style device trust and restricted ACLs can confine the session to low-value resources
- No credential reuse means the attacker may end with reconnaissance only
Escalate to post-exploitation with common ransomware tooling
Cobalt Strike beacon, and tried a BYOVD driver load to blind EDR. That is the practical impact amplifier: even though the initial flaw is 'just MFA bypass,' the payoff is a trusted foothold that can become pre-ransomware staging fast.- The VPN account can reach a host with admin paths available
- Shared local admin credentials or other reusable creds exist
- Endpoint protections are weak or absent
- EDR blocked both the beacon and the vulnerable-driver load in the published case
- Unique local admin credentials and server-tier isolation can dead-end the intrusion
- Noisy post-exploitation steps are much easier to catch than the initial login
Cobalt Strike, vulnerable-driver loads, RDP from VPN pools, and manual credential hunting on file servers.The supporting signals.
| In-the-wild status | At disclosure on 2025-01-09, CISA ADP metadata showed exploitation none; later, ReliaQuest reported the first known in-the-wild exploitation with medium confidence across multiple environments between February and March 2026. |
|---|---|
| PoC availability | I did not find a reliable public exploit repo or Exploit-DB entry for this CVE. ReliaQuest says the specific sess="CLI" tool was not confirmed, which lowers copy-paste exploitability. |
| EPSS | 0.07% (21st percentile) per GitHub's EPSS display sourced from FIRST — low statistical likelihood compared with headline edge bugs. |
| KEV status | Not listed in CISA KEV as checked against the catalog; contrast that with SonicWall CVE-2024-40766, which *is* KEV-listed. No federal deadline signal here. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N reads like a pure unauthenticated network bug, but that model ignores the real prerequisite of working credentials / credential spraying and the specific AD naming configuration. |
| Affected versions | Published CVE record lists Gen6 NSv 6.5.4.4-44v-21-2457 and older, Gen6 hardware 6.5.4.15-117n and older, Gen7 NSv 7.0.1-5161 and older, Gen7 hardware 7.1.1-7058 and older, 7.1.2-7019, and TZ80 8.0.0-8035. |
| Fixed versions | Advisory mirrors report fixes at 6.5.4.4-44v-21-2472, 6.5.5.1-6n, 7.0.1-5165, 7.1.3-7015, and 8.0.0-8037. Important: for Gen6, firmware alone is insufficient; the six LDAP reconfiguration steps are part of the fix state. |
| Scanning / exposure data | I did not locate a trustworthy CVE-specific GreyNoise or Censys count for CVE-2024-12802 itself. As a bounding data point, Censys observed 5,065 exposed SonicWall TZ/NSa/NSsp/NSv instances for the related SSLVPN auth-bypass advisory on CVE-2024-53704; inference: the reachable population for SonicWall SSLVPN edge exposure is non-trivial, but this CVE's *truly exploitable* population is narrower because it also needs AD-backed SSLVPN and the vulnerable identity-path handling. |
| Disclosure date | CVE published 2025-01-09; SonicWall's support notice on the configuration conditions was published 2025-03-04 and updated 2025-06-05. |
| Researcher / reporting org | The CVE record says discovery was external but does not publicly name the finder. Operational exploitation reporting and the best public attack-chain detail come from ReliaQuest Threat Research. |
noisgate verdict.
The single most important severity brake is that this is credential-dependent in practice: attackers still need a valid account or a brute-forceable one, so the real-world population is much smaller than the CVSS PR:N story suggests. It still lands in HIGH because the target is an internet-facing VPN edge, exploitation has now been observed in the wild, and Gen6 remediation can be falsely reported as complete when it is not.
Why this verdict
- Start at 9.1, then cut for attacker prerequisites: despite the CVSS
PR:N, real exploitation usually needs a real VPN credential or successful spraying, which is a major downgrade from a true no-auth edge compromise. - Cut again for reachable population: only deployments with externally exposed SSLVPN, Microsoft AD-backed auth, and the vulnerable UPN/SAM handling are in scope; that is a much narrower slice than 'all SonicWall internet edge.'
- Add risk back for operational reality: ReliaQuest saw in-the-wild exploitation on Gen6 devices that looked patched because firmware version alone did not equal remediation, which makes this materially more dangerous than a routine config bug.
Why not higher?
I am not scoring this CRITICAL because most attackers cannot walk up anonymously and win. They need external SSLVPN exposure, the right AD/LDAP design, and usually a usable credential path; that compounds friction fast. Low EPSS and no KEV listing also argue against top-bucket urgency on pure prevalence grounds.
Why not lower?
I am not dropping this to MEDIUM because the payoff is still initial network access through the corporate VPN and the failure mode is silent MFA collapse. Once a sprayed or stolen account works, perimeter controls are bypassed and the attacker can reach internal systems in minutes. The Gen6 'patched but still exposed' trap is exactly the kind of operational gap that produces real incidents.
What to do — in priority order.
- Restrict or disable exposed SSLVPN now — If Gen6 SSLVPN is internet-facing, treat this as an exposed single-factor path until proven otherwise. Disable it where possible or restrict it to allowlisted source IPs / jump networks; because there is active exploitation evidence, apply this immediately, within hours.
- Verify the Gen6 six-step remediation separately from firmware — Do not trust a green version check. Track firmware upgrade and LDAP reconfiguration as separate controls, and require evidence that the advisory's six Gen6 steps were completed on every affected firewall; because active exploitation exists, complete this verification immediately, within hours.
- Reset exposed VPN credentials and enforce lockout — ReliaQuest observed brute-force leading into the bypass, so password resets, stronger lockout / rate-limit controls, and removal of dormant VPN users directly attack the most important prerequisite. Do this immediately, within hours for exposed Gen6 populations.
- Constrain VPN-to-server reachability — The impact spike comes after login, when reused credentials and broad VPN ACLs let an attacker pivot to file servers or admin paths. Tighten ACLs, segregate VPN client pools, and block direct access from non-trusted VPN endpoints to server tiers immediately, within hours where exposure remains.
- Turn on detections for
sess="CLI", RDP from VPN pools, and BYOVD — The initial bypass is quiet, but the campaign left a repeatable auth-log signal and later used standard post-exploitation tradecraft. Forward SonicWall auth logs to SIEM, alert onsess="CLI"plus Event IDs238/1080, and ensure EDR vulnerable-driver blocking is enabled immediately, within hours.
- A firmware-only compliance report does not prove safety on Gen6; ReliaQuest's core finding was that patched version checks can still leave the device exploitable.
- A green 'MFA enabled' dashboard is not enough, because the flaw is specifically about inconsistent enforcement across
UPNvsSAMlogin paths. - A generic WAF in front of the firewall is mostly irrelevant here; the attack is authentication workflow abuse on the VPN edge, not typical web payload injection.
Crowdsourced verification payload.
Run this on an auditor workstation or in CI against a CSV export from your firewall inventory / CMDB. Invoke it as python3 verify_cve_2024_12802.py inventory.csv with no special privileges; the CSV must contain hostname,platform,version,sslvpn_enabled,auth_backend,extra_upn_suffix,gen6_manual_remediation_complete.
#!/usr/bin/env python3
# verify_cve_2024_12802.py
# Inventory-based verifier for SonicWall CVE-2024-12802
# Output per row: VULNERABLE / PATCHED / UNKNOWN
# Exit codes:
# 0 = all assessed rows PATCHED
# 1 = one or more rows VULNERABLE
# 2 = no VULNERABLE rows, but one or more UNKNOWN rows
# 3 = usage / file / parsing error
import csv
import re
import sys
from typing import Tuple
REQUIRED = [
'hostname',
'platform',
'version',
'sslvpn_enabled',
'auth_backend',
'extra_upn_suffix',
'gen6_manual_remediation_complete'
]
FIXED = {
'gen6_nsv_6.5.4.4': '6.5.4.4-44v-21-2472',
'gen6_hw': '6.5.5.1-6n',
'gen7_nsv': '7.0.1-5165',
'gen7_hw': '7.1.3-7015',
'tz80': '8.0.0-8037',
}
def norm_bool(v: str):
if v is None:
return None
s = str(v).strip().lower()
if s in ('1', 'true', 'yes', 'y', 'enabled'):
return True
if s in ('0', 'false', 'no', 'n', 'disabled'):
return False
return None
def version_key(v: str) -> Tuple[int, ...]:
nums = re.findall(r'\d+', v or '')
return tuple(int(x) for x in nums)
def ge(v1: str, v2: str) -> bool:
return version_key(v1) >= version_key(v2)
def classify_branch(platform: str, version: str):
p = (platform or '').strip().lower()
v = (version or '').strip().lower()
if 'tz80' in p:
return 'tz80'
if 'gen7' in p and 'nsv' in p:
return 'gen7_nsv'
if 'gen7' in p:
return 'gen7_hw'
if 'gen6' in p and 'nsv' in p:
if v.startswith('6.5.4.4-44v-21-'):
return 'gen6_nsv_6.5.4.4'
return 'gen6_nsv_6.5.4.4'
if 'gen6' in p:
return 'gen6_hw'
# Fallback from version only
if v.startswith('8.0.0-'):
return 'tz80'
if v.startswith('7.0.1-'):
return 'gen7_nsv'
if v.startswith('7.1.'):
return 'gen7_hw'
if v.startswith('6.5.4.4-44v-21-'):
return 'gen6_nsv_6.5.4.4'
if v.startswith('6.5.'):
return 'gen6_hw'
return None
def assess(row):
host = row['hostname']
version = (row['version'] or '').strip()
platform = (row['platform'] or '').strip()
sslvpn = norm_bool(row['sslvpn_enabled'])
auth_backend = (row['auth_backend'] or '').strip().lower()
extra_upn = norm_bool(row['extra_upn_suffix'])
gen6_steps = norm_bool(row['gen6_manual_remediation_complete'])
if not version or not platform:
return host, 'UNKNOWN', 'missing platform/version'
branch = classify_branch(platform, version)
if branch is None:
return host, 'UNKNOWN', 'unrecognized SonicOS branch'
# Reachability / applicability gates
if sslvpn is False:
return host, 'PATCHED', 'SSLVPN disabled; issue not reachable'
if sslvpn is None:
return host, 'UNKNOWN', 'unknown whether SSLVPN is enabled'
if auth_backend not in ('ad', 'ldap', 'active_directory', 'microsoft_ad', 'microsoft ldap'):
return host, 'PATCHED', 'not using AD/LDAP-backed SSLVPN auth'
if extra_upn is False:
return host, 'PATCHED', 'no extra AD UPN suffix indicated'
if extra_upn is None:
return host, 'UNKNOWN', 'unknown whether extra AD UPN suffix / alternate UPN path exists'
fixed = FIXED[branch]
at_or_above_fixed = ge(version, fixed)
# Branch-specific handling
if branch in ('gen6_hw', 'gen6_nsv_6.5.4.4'):
if not at_or_above_fixed:
return host, 'VULNERABLE', f'firmware below fixed level {fixed}'
if gen6_steps is True:
return host, 'PATCHED', 'firmware fixed and Gen6 manual remediation confirmed'
if gen6_steps is False:
return host, 'VULNERABLE', 'firmware fixed but Gen6 manual remediation incomplete'
return host, 'UNKNOWN', 'firmware fixed but Gen6 manual remediation status unknown'
# Gen7 / TZ80: firmware is the dominant remediation signal per published reporting
if not at_or_above_fixed:
return host, 'VULNERABLE', f'firmware below fixed level {fixed}'
return host, 'PATCHED', 'firmware at or above fixed level'
def main():
if len(sys.argv) != 2:
print('Usage: python3 verify_cve_2024_12802.py inventory.csv', file=sys.stderr)
sys.exit(3)
path = sys.argv[1]
vulnerable = 0
unknown = 0
try:
with open(path, newline='', encoding='utf-8-sig') as f:
reader = csv.DictReader(f)
missing = [c for c in REQUIRED if c not in (reader.fieldnames or [])]
if missing:
print('Missing required columns: ' + ', '.join(missing), file=sys.stderr)
sys.exit(3)
for row in reader:
host, state, reason = assess(row)
print(f'{host},{state},{reason}')
if state == 'VULNERABLE':
vulnerable += 1
elif state == 'UNKNOWN':
unknown += 1
except FileNotFoundError:
print(f'File not found: {path}', file=sys.stderr)
sys.exit(3)
except Exception as e:
print(f'Error: {e}', file=sys.stderr)
sys.exit(3)
if vulnerable:
sys.exit(1)
if unknown:
sys.exit(2)
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- SonicWall support notice: SSL-VPN MFA Bypass CVE-2024-12802
- SonicWall PSIRT advisory SNWLID-2025-0001
- OpenCVE record for CVE-2024-12802
- GitHub Advisory Database entry GHSA-ff32-cmvq-x6c5
- ReliaQuest threat spotlight on active exploitation
- CISA Known Exploited Vulnerabilities catalog
- Censys advisory with SonicWall SSLVPN exposure context
- BleepingComputer coverage of ReliaQuest findings
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.