What happened

SonicWall released updates for seven vulnerabilities in SonicOS. The one drawing attention is CVE-2026-19868, an authentication bypass in the SSL-VPN service with a CVSS score of 7.1. According to reporting by BleepingComputer, an attacker who holds valid credentials for an alternate authentication method can bypass SAML authentication controls, which can include SAML-enforced multi-factor authentication. It only affects SSL-VPN services configured to use SAML.

SonicWall states that its PSIRT investigated a report indicating potential exploitation and urges customers to upgrade. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog and set a deadline of November 20, 2026 for federal civilian agencies. The vulnerability was reported by Ryan Harris of The Electronic Office.

Affected versions are SonicOS Gen7 7.3.3-7015 and earlier, and Gen8 8.2.2-8015 and earlier. Fixes are in 7.3.4-7013 and 8.2.3-8015. According to the reporting, SonicWall lists no workarounds. The same release addresses six other flaws: two management interface issues rated 8.8 that let unauthenticated attackers perform unauthorized operations under specific conditions, pre-authentication buffer overflows in SSL-VPN and TACACS+ that can cause denial of service, and a weak password hashing issue on virtual appliances.

Why it matters

Many organizations treat SAML with MFA on the VPN as the control that stops stolen passwords. This bug is a reminder that the control only holds if every other path into the same portal is closed. The attacker still needs valid credentials for an alternate method, so the realistic starting point is credential theft, reuse or an infostealer log. If those credentials exist, the MFA step you counted on may not be enforced.

Remote access appliances are also a favorite initial access target. A VPN session lands an attacker inside the network with a legitimate-looking source, so the first signs often appear in identity and file server logs rather than on the firewall.

What defenders should check

  • Firmware: confirm the running SonicOS version on every Gen7 and Gen8 firewall and plan the upgrade to 7.3.4-7013 or 8.2.3-8015.
  • Configuration: identify which SSL-VPN portals use SAML, and which other authentication methods (local users, RADIUS, LDAP) are enabled on the same portal. Disable what you do not need.
  • Exposure: list internet-facing SonicWall interfaces you own, including forgotten branch devices. Shodan or Censys filters scoped to your own organization, for example org:"<your org>", help find them. Verify firmware from the admin interface, not from banners.
  • Management plane: make sure the management interface is not reachable from the internet, given the other fixed flaws.
  • Credentials: check for exposed or reused passwords for VPN users, and prioritize accounts without any other protection.

Detection ideas

These are starting points to adapt and test in your environment, not production-ready rules. The idea is to find VPN sessions that succeeded without a matching identity provider sign-in.

// Sketch: VPN success with no IdP sign-in for the same user
let vpn = SonicWallVpnLogs
  | where Action == "login_success"
  | where TimeGenerated > ago(30d)
  | project VpnTime = TimeGenerated, User, SrcIp;
vpn
| join kind=leftanti (
    SigninLogs
    | where AppDisplayName has "SonicWall"
    | project User = UserPrincipalName
  ) on User

Adjust table and field names to your log source. A time-window join (for example two minutes) on user is stricter when clocks are aligned.

# Quick log grep: successful SSL-VPN logins counted per line
grep -i "sslvpn" sonicwall.log | grep -i "success" | sort | uniq -c | sort -rn

Also alert on a VPN login from a new country or ASN for a user, a login outside normal hours, and a user connecting from two distant locations within a short time.

Investigation

If you suspect abuse of this flaw, collect evidence before patching or rebooting where you can:

  • Export the firewall's SSL-VPN authentication logs and the configuration, then record the exact firmware version.
  • Pull the identity provider sign-in logs for the same window and compare them to VPN sessions by user and time.
  • Identify the VPN-assigned internal IP for each suspect session and follow it through DHCP, DNS, domain controller (Event IDs 4624 and 4768/4769) and file server logs.
  • Look for new local accounts, changed portal settings or new admin users on the firewall.
  • Check endpoint telemetry on systems the session touched for remote tools, credential dumping and data staging.
  • Preserve the logs off-box, since appliance log retention is often short.

If a session without an IdP match is confirmed, treat the account as compromised: reset its credentials, revoke tokens and sessions, and widen the review to other users whose credentials may have leaked the same way. Our incident response and threat hunting teams work on exactly this kind of scoping.

Mitigation

  • Upgrade to SonicOS 7.3.4-7013 (Gen7) or 8.2.3-8015 (Gen8). SonicWall reports no workarounds, so patching is the fix.
  • Disable authentication methods you do not use on SSL-VPN portals, so a single working method cannot sidestep SAML.
  • Restrict management interface access to trusted internal networks.
  • Rotate VPN credentials after patching if you saw any suspicious session, and enforce unique passwords.
  • Keep VPN log retention long enough to look back several weeks, and forward the logs to your SIEM.
  • Follow the official SonicWall advisory and CISA's KEV entry for updates, since details of the exploitation have not been published.

The broader pattern is worth noting: the reporting links this to repeated attacks on SonicWall remote access products over the past months. Plan for faster patch cycles on edge devices and keep an inventory you trust.