CVE-2026-19868: SonicWall SSL-VPN flaw skips SAML MFA, now exploited

SonicWall published advisory SNWLID-2026-0014 on November 6, 2026, fixing seven vulnerabilities in SonicOS for Gen 7 and Gen 8 firewalls. One of them, CVE-2026-19868, lets someone holding a valid password for a non-SAML login method open an SSL-VPN session without going through SAML, and so without the multi-factor prompt the identity provider would have enforced. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until November 20 to fix it.

SonicWall says its product security team "investigated a report indicating potential exploitation." Neither SonicWall nor CISA has published attacker details, victim counts, or indicators of compromise, and it is unclear whether the flaw was used before patched builds were available.

How the SAML bypass works

Many offices put SSL-VPN logins behind SAML so users authenticate through Microsoft Entra ID, Okta, Duo, or another identity provider, which then requires MFA. The firewall is supposed to insist on that SAML assertion. Under CVE-2026-19868, the SSL-VPN service fails to enforce the SAML requirement for an account that can also authenticate another way. An attacker who logs in through that alternate path with a correct password never reaches the identity provider, and the MFA step never runs.

The attacker still needs a working credential. Phished, reused, and brute-forced VPN passwords are common, which is why companies added MFA to the VPN in the first place. SonicWall has not said which alternate method is involved. SonicOS can authenticate SSL-VPN users against its local user database, LDAP, or RADIUS, so treat each of those as a possible bypass path until the firmware is updated.

Scores differ by source. SonicWall rates the flaw CVSS 7.1 with a vector that assumes a low-privilege account (PR:L). The CISA score in the NVD record is 7.5 with no privileges required (PR:N). The weakness is CWE-308, use of single-factor authentication. SonicWall says only firewalls with SAML enabled for SSL-VPN are exposed.

Affected SonicOS builds and fixed releases

• Gen 7 TZ, NSa, NSsp and NSv: SonicOS 7.3.3-7015 and earlier are affected. Fixed in 7.3.4-7013 and later.
• Gen 8 TZ, NSa and NSv: SonicOS 8.2.2-8015 and earlier are affected. Fixed in 8.2.3-8015 and later.

Both hardware appliances and NSv virtual firewalls are covered. SonicWall lists no workaround; the firmware upgrade is the only vendor fix.

Six other SonicOS flaws fixed in the same builds

None of these is reported as exploited:

• Two management-interface bugs rated CVSS 8.8, one a permissive cross-domain policy and one a session validation flaw. Under certain conditions either lets an unauthenticated remote attacker perform unauthorized actions.
• Three pre-authentication buffer overflows in the SSL-VPN service and the TACACS+ authentication client. SonicWall and press coverage describe them as denial-of-service bugs.
• Weak password hashing on virtual appliances, which can give an attacker who already has high-privilege local access a platform credential.

A firewall that crashes on a crafted pre-auth request takes the office network down with it, so the overflow fixes justify the upgrade for any site running SSL-VPN, SAML or not.

Gen 6 SonicWall firewalls get no fix

Gen 6 appliances reached end of life on April 16, 2026 and receive no firmware updates. They also carry an older MFA problem. In February and March 2026, ReliaQuest observed attackers brute-forcing VPN passwords and getting past MFA through CVE-2024-12802 on Gen 6 units. Those units had the firmware fix installed but not the manual follow-up from advisory SNWLID-2025-0001, which requires deleting the LDAP configuration and rebuilding it without the userPrincipalName format. An office still running a Gen 6 unit with SSL-VPN open to the internet has no patch path and should plan replacement hardware.

Upgrade and audit steps for SonicWall admins

• Record the current SonicOS build for every firewall, including NSv instances in cloud or VMware environments that are easy to forget.
• Export a configuration backup before upgrading. The upgrade reboots the appliance, so schedule a window.
• Upgrade Gen 7 to 7.3.4-7013 or later and Gen 8 to 8.2.3-8015 or later.
• List every user and group with SSL-VPN access. For users who should sign in only through SAML, confirm they have no local password and that no LDAP or RADIUS group also grants them SSL-VPN access. Remove alternate methods nobody needs.
• Restrict SSL-VPN to known source addresses where the business can.
• Confirm HTTPS and SSH management are not reachable from the WAN. The two 8.8 management bugs require network access to that interface.
• Reset passwords on shared VPN accounts and on accounts used by former contractors.

Signs of a bypassed login in SSL-VPN logs

SonicWall has published no indicators, so the check is manual. Pull SSL-VPN authentication events for the past several weeks and look for accounts that should log in only through SAML but show a local, LDAP, or RADIUS authentication. Compare source IPs and login times against each user's normal pattern, and look for new local users or new SSL-VPN group memberships. If a login cannot be explained, reset that account's credentials at both the identity provider and the firewall, then review which internal hosts the session reached and check them for new accounts, scheduled tasks, or remote access tools.

Office VPNs often reach the same file servers, databases, and admin panels behind a company's website and email. At Falcon Internet we keep SSH and management interfaces on our hosting network limited to allowlisted addresses, and a SonicWall management page or SSL-VPN portal open to any source address deserves the same restriction.