SonicWall SSL VPN bug lets a password skip SAML and MFA
CVE-2026-19868 is exploited and on CISA KEV. Gen7 and Gen8 firewalls with SAML SSL VPN need 7.3.4-7013 or 8.2.3-8015. Builds, checks and cleanup.
By Yaali. November 9, 2026, 6 min read, Vulnerabilities, Identity, Patching.
On November 6, SonicWall published advisory SNWLID-2026-0014, fixing seven SonicOS vulnerabilities in its Gen7 and Gen8 firewalls. One of them, CVE-2026-19868, lets someone with valid credentials for a different login method get past SAML on the SSL VPN, along with any multi-factor authentication (MFA) that the SAML identity provider enforces. SonicWall says its product security team "has investigated a report indicating potential exploitation", and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog the same day, with a November 20 deadline for US federal agencies.
You are exposed if a Gen7 TZ, NSa, NSsp or NSv firewall runs SonicOS 7.3.3-7015 or older, or a Gen8 TZ, NSa or NSv runs 8.2.2-8015 or older, and SAML is enabled for SSL VPN logins. Firewalls that do not use SAML for the SSL VPN are not affected by this CVE, though they still need the update for the other six. SonicWall offers no workaround.

How it works
Security Assertion Markup Language (SAML) moves the login off the firewall. When SSL VPN > Server Settings has the authentication type set to SAML, the Virtual Office portal and the NetExtender client stop asking for a password and send the user to the identity provider, such as Microsoft Entra ID or Okta. The provider checks the password and the second factor, then hands back a signed assertion saying who the user is. Organizations switch to SAML precisely so that MFA and Conditional Access rules apply to every VPN login.
A SonicOS firewall can also authenticate users against its local user database, LDAP or RADIUS. CVE-2026-19868 is classed as CWE-308, use of single-factor authentication: SonicWall's description says a user "with valid credentials for an alternate authentication method" can bypass the SAML controls. In plain terms, the SSL VPN still accepts one of those older username and password paths when it should only accept a SAML assertion, and that path never calls the identity provider, so its MFA never runs.
SonicWall has not said which alternate method is involved. One detail is worth checking in your own setup: SonicWall's own guidance for SAML on SSL VPN tells administrators to create a local user with the same name as the SAML user when that person also needs to manage the firewall. Those local accounts have passwords of their own, set on the firewall and often forgotten.
The two scores differ for this reason. SonicWall rates it 7.1 with "privileges required: low", because the attacker needs a working password. The CISA-supplied score in the National Vulnerability Database (NVD) is 7.5 with no privileges required. Either way, the attacker must already hold a working password for one of the alternate login methods.
What attackers are doing
Little is public. Neither SonicWall nor CISA has described the attacks, named an actor or published indicators, and it is not known whether the bug was used before the fix shipped. The flaw was reported by Ryan Harris of The Electronic Office. CISA's KEV entry calls it "SonicWall SonicOS SSLVPN Use of Single-factor Authentication Vulnerability" and points agencies at its forensics triage requirements as well as the patch. For defenders, that means the patch has to come with a look back through VPN logins, covered below.
The other six fixes

The highest scores in the advisory go to two management interface bugs. CVE-2026-107155, a permissive cross-domain policy, and CVE-2026-107154, a session check that relies on the client's IP address, are both rated 8.8 and can let a remote attacker who has not logged in perform actions on the firewall "in specific conditions"; their CVSS vector marks them as needing user interaction. If your management interface faces the internet, that is a second reason to upgrade this week.
CVE-2026-82308 is a pre-authentication heap overflow in the SSL VPN service that can crash it (7.5), and CVE-2026-77708 and CVE-2026-77709 do the same to the TACACS+ authentication client (5.9). CVE-2026-19703 (5.2) is weak password hashing on NSv virtual appliances that lets someone with high-privilege local access recover a platform credential.
What to do
- Find every affected firewall. Read the firmware version on each Gen7 and Gen8 unit, then check SSL VPN > Server Settings for authentication type SAML. Units with SAML on are the urgent ones; the rest still get the update.
- Upgrade. Gen7 goes to SonicOS 7.3.4-7013 or later and Gen8 to 8.2.3-8015 or later, as listed in SonicWall's advisory, NVD and SecurityWeek. Canada's Cyber Centre bulletin AV26-1133 lists Gen8 as affected "prior to 8.2.2-8015", which would leave 8.2.2-8015 itself out; SonicWall lists 8.2.2-8015 as affected, so go by the vendor and install 8.2.3-8015.
- If you cannot upgrade today. SonicWall gives no workaround. Our suggestion, not SonicWall's: remove or disable local, LDAP and RADIUS accounts that can reach the SSL VPN and are not needed, set long random passwords on the local admin accounts created for SAML users, and limit SSL VPN access to known source addresses where your users allow it. Turning the SSL VPN off until the upgrade is the only option that fully closes it.
- Check for past abuse. Every legitimate SAML login to the VPN should have a matching sign-in at your identity provider, for the SonicWall enterprise application, at the same time and for the same user. Turn on event 1080, "Successful SSLVPN User Login", under Device > Log > Settings, Users, Group Authentication Access, if it is not already logged, and compare those events, along with the Client WAN IP column on Network > SSL VPN > Status, with the provider's sign-in log. A VPN login with no matching provider sign-in, or from an address your users never use, is the pattern to chase.
- Clean up: reset the passwords of every account that could use an alternate login method, end active SSL VPN sessions after the upgrade, and look at what any suspicious session reached on the internal network.
The wider lesson
MFA at the identity provider only protects the doors that send users to it. Whenever a VPN, a firewall or an application moves to single sign-on, list every other way it can still authenticate someone, such as local break-glass accounts, LDAP binds or RADIUS, and test that each one is really refused for normal users.
We check exactly these fallback paths on edge devices during network penetration testing, and safeguarding and hardening covers VPN and identity configuration. If you are not sure whether your SonicWall still accepts a password where it should demand SAML, open the chat and Yaali, our AI agent, will pass the question to an engineer.
Sources: SonicWall PSIRT SNWLID-2026-0014, CISA KEV alert, NVD CVE-2026-19868, SecurityWeek, Canadian Centre for Cyber Security AV26-1133, SonicWall SAML for SSL VPN guide, SonicWall KB: SSLVPN SAML and firewall management, SonicWall KB: monitoring SSLVPN logins.
Read next
- OpenSSH 10.6p2: long passwords open locked Alpine accounts
- GoAhead TLS flaws: revoked certificates still get in
- Authenticator for Android handed work tokens to any app
Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.