SonicWall SSLVPN Flaw CVE-2026-19868 Lets Valid Non-SAML Credentials Skip SAML and Its MFA — Exploited in the Wild, CISA Gives Agencies Until 20 November

High · 2026-11-07 · By H.A

SonicWall confirms attackers are exploiting a SonicOS SSLVPN flaw that lets credentials for an alternate login method bypass SAML authentication and SAML-enforced MFA, and CISA has added it to KEV.

Overview

SonicWall has confirmed that CVE-2026-19868, an authentication enforcement flaw in the SonicOS SSLVPN service, is being exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 6 November 2026, the same day the vendor published advisory SNWLID-2026-0014, and set a remediation deadline of 20 November 2026 for U.S. federal agencies.

The flaw does not hand attackers a shell. It does something that matters more for many organisations: it lets someone who holds valid credentials for a different login method get through an SSLVPN that the administrator believed was locked behind SAML single sign-on, and potentially behind the MFA that the SAML identity provider enforces. Stolen VPN credentials are one of the most common ransomware entry points, and this bug can turn a password that "should not work any more" back into a working tunnel.

The Vulnerability

• CVE: CVE-2026-19868 (CWE-308, Use of Single-Factor Authentication)
• Vendor advisory: SNWLID-2026-0014
• CVSS 3.1: 7.5 High, vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N as published in the CVE record
• Affected (CVE record): SonicOS 7.3.3-7015 and older, and SonicOS 8.2.2-8015 and older
• Exposure condition: SSLVPN with SAML authentication configured

According to the vendor description, "a user with valid credentials for an alternate authentication method" can bypass the SAML authentication controls on the SSLVPN service, and successful exploitation "may also bypass SAML-enforced MFA." In practice this concerns appliances where SAML was layered on top of an existing setup: local user accounts, LDAP or RADIUS credentials that still exist on the firewall can be presented through a path that skips the identity provider.

Public sources disagree on the exact affected range — Canada's Cyber Centre advisory AV26-1133 describes versions earlier than 7.3.4-7013 for the 7.x branch — so administrators should confirm the fixed build for their platform directly in SNWLID-2026-0014 rather than relying on third-party summaries. SonicWall disclosed the flaw together with six other SonicOS vulnerabilities on the same day.

Timeline

• 14 August 2026: CVE identifier reserved by SonicWall.
• 6 November 2026: SonicWall publishes SNWLID-2026-0014 and reports active exploitation; the CVE record goes live; Canada's Cyber Centre issues AV26-1133.
• 6 November 2026: CISA adds CVE-2026-19868 to KEV. Ransomware use is listed as "unknown".
• 20 November 2026: Federal remediation deadline.

No threat actor, victim or start date for the exploitation has been published.

Tradecraft

The exploitation prerequisite is a valid credential, not a vulnerability chain. That makes the realistic attack path:

• Credentials harvested by infostealers, purchased from access brokers, or reused from earlier SonicWall incidents (including configuration and credential exposures in previous years) are tried against the SSLVPN portal.
• Where the organisation moved to SAML and MFA but left local or directory-backed accounts able to authenticate, those credentials succeed without the identity provider ever seeing the login.
• Once the tunnel is up, activity looks like an ordinary remote user: internal reconnaissance, RDP and SMB movement, then data theft or ransomware staging.

SonicWall SSLVPN has repeatedly been a favoured entry point for ransomware affiliates, so this is the scenario defenders should plan for even though no ransomware link is confirmed yet.

Indicators of Compromise

Neither SonicWall nor CISA has published IP addresses, hashes or other indicators for this activity.

Detection

• Pull SSLVPN authentication logs for the past 90 days and list every successful login that did not go through the SAML identity provider. On a SAML-only design that list should be empty.
• Correlate firewall VPN logins with sign-in logs at the identity provider (Entra ID, Okta, etc.). A VPN session with no matching IdP sign-in and MFA event is the key signal.
• Flag logins from local firewall accounts, service accounts or LDAP users who normally never use the VPN.
• Look for VPN sessions from hosting providers, VPS ranges or unusual countries, and for rapid internal scanning (SMB, RDP, LDAP) shortly after a tunnel is established.

Recommended Actions

1. Upgrade every SonicOS 7.x and 8.x firewall running SSLVPN to the fixed build listed in SNWLID-2026-0014.
2. Until patched, remove or disable alternate authentication paths for SSLVPN: local user accounts, LDAP/RADIUS groups with SSLVPN access, and any legacy portal method. If SAML cannot be the only path, consider disabling SSLVPN on WAN interfaces temporarily.
3. Reset passwords for all accounts that are able to authenticate to the SSLVPN through a non-SAML method, and remove stale accounts.
4. Hunt using the detection steps above, and treat any VPN login that bypassed the IdP as a potential intrusion.
5. Restrict exposure of the SSLVPN and management interfaces with geo/IP allow-lists where business needs allow.
6. Confirm that firewall configuration backups and credentials stored on the device have not been exposed in earlier incidents; rotate them if in doubt.

Analyst Assessment

CVE-2026-19868 carries a "High" score because it needs a valid credential, but in the real world valid credentials are abundant. The flaw undermines the specific control organisations deployed to make stolen passwords useless — SAML with MFA — and it is already being used. Given SonicWall's history as a ransomware entry point and the short federal deadline, we rate the practical risk as High to Critical for any organisation with SAML-protected SSLVPN on an affected build. Patch first; then verify, from logs, that no one has already walked in through the side door.