HIGH: SonicWall SonicOS SSL VPN Flaw Lets Attackers Skip SAML MFA

Multi-factor authentication is supposed to be the thing that saves you when a password leaks. It is the control every cyber insurance questionnaire asks about and every auditor wants to see screenshots of. So it stings a little when the VPN appliance enforcing it turns out to have a side door that skips the second factor entirely. That is the situation SonicWall customers are in this week, and CISA has made it clear this is not a theoretical problem.

On November 6, 2026, SonicWall published advisory SNWLID-2026-0014 for CVE-2026-19868, an authentication enforcement flaw in the SSL VPN service of SonicOS, the operating system that runs its Gen7 and Gen8 firewalls. The same day, CISA added the bug to its Known Exploited Vulnerabilities catalog under the name "SonicWall SonicOS SSLVPN Use of Single-factor Authentication Vulnerability" and gave federal civilian agencies until November 20 to fix it. SonicWall itself said it "investigated a report indicating potential exploitation of this vulnerability," which is vendor language for "somebody has been using this and we found out the hard way."

What CVE-2026-19868 actually does

SonicWall describes the issue as a flaw that "may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls." The advisory goes on to say that successful exploitation may also bypass SAML-enforced multi-factor authentication. The weakness is classified as CWE-308, use of single-factor authentication, and that label tells you most of what you need to know.

Here is the plain English version. Plenty of organizations front their SonicWall SSL VPN with SAML single sign-on through Entra ID, Okta, Duo, or a similar identity provider, and they lean on that provider to enforce MFA and conditional access. The firewall, however, often still has other ways to authenticate a user sitting behind the scenes. Think local user accounts on the appliance, LDAP or RADIUS binds against Active Directory, or leftover configuration from before the SAML migration. CVE-2026-19868 means that an attacker holding valid credentials for one of those alternate methods can log in through that path, and SonicOS fails to insist that the SAML flow, with its MFA prompt, actually happened. The attacker gets a VPN session with a username and password, which is exactly the outcome your MFA rollout was supposed to prevent.

If this sounds familiar, it should. SonicWall has been here before with CVE-2024-12802, a Gen6 SSL VPN issue where the appliance treated UPN and SAM account name logins as separate paths, letting someone with valid credentials pick whichever path did not trigger MFA. Researchers reported in 2026 that exploitation of that older bug was hitting Gen6 boxes, and some patched devices remained exposed because the fix required manual configuration steps that many admins never took. The theme is consistent. When an edge device supports more than one way to prove who you are, attackers will find the way with the fewest questions.

The CISA ADP entry scores CVE-2026-19868 at CVSS 7.5 with the vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N. The Hacker News also reported a 7.1 score, so expect the number to wobble a bit as NVD finishes its analysis. Do not let the "High" rather than "Critical" label lull you into a slow patch cycle. The high attack complexity reflects the fact that the attacker needs working credentials first. In 2026 that is not a high bar. Infostealer logs are sold by the gigabyte, password reuse is still the national pastime, and VPN credential spraying runs around the clock against every SonicWall portal Shodan can find. CVSS measures the bug in isolation. Your risk is the bug multiplied by the pile of stolen passwords already floating around for your users.

Affected versions and patches

According to the CVE record published by SonicWall, the flaw affects SonicOS on Gen7 and Gen8 platforms, specifically Gen7 builds 7.3.3-7015 and older and Gen8 builds 8.2.2-8015 and older. The Canadian Centre for Cyber Security advisory AV26-1133 lists affected Gen7 builds as those prior to 7.3.4-7013, which points to 7.3.4-7013 as the fixed Gen7 release. The Gen8 cutoff is less tidy, because the CVE record lists 8.2.2-8015 as affected while the Canadian advisory frames it as the boundary. The safe move is to pull up SNWLID-2026-0014 on the SonicWall PSIRT portal, confirm the fixed build for your exact model, and go to the newest firmware SonicWall offers for that platform rather than the bare minimum. That covers the TZ, NSa, and NSsp lines along with the virtual NSv appliances running in AWS, Azure, and on-premises hypervisors.

The same advisory cycle also brought fixes for several other SonicOS bugs that deserve a spot on the change ticket. CVE-2026-107155 and CVE-2026-107154 are both rated CVSS 8.8 and affect the management interface, one a permissive cross-domain policy issue and the other a session validation flaw, and each could let a remote unauthenticated attacker perform unauthorized actions under specific conditions. CVE-2026-82308 is a CVSS 7.5 pre-authentication heap-based buffer overflow in the SSL VPN service that can crash the service. None of those are listed as exploited yet, but a single firmware upgrade takes care of all four, so there is no reason to do this twice.

SonicWall also disclosed two flaws in its end-of-life Global Management System, CVE-2026-109593 and CVE-2026-109594, which will not be patched. If you still have GMS humming along in a closet somewhere, this is your sign to finish the move to Network Security Manager.

Who is affected and what exploitation looks like

The exposed population is any organization running SSL VPN on a Gen7 or Gen8 SonicWall with SAML authentication and at least one other authentication source still enabled. That describes a lot of small and midsize businesses, because SonicWall firewalls are a staple of the SMB and MSP market and SAML is usually layered on top of an existing LDAP or local user setup rather than replacing it.

SonicWall has not published indicators, attribution, or details on how many customers were hit. Still, history gives us a decent playbook. SonicWall SSL VPN has been a favorite initial access point for ransomware crews over the past two years, with Akira and Fog affiliates in particular logging in with valid credentials, moving laterally within hours, and encrypting hypervisors before anyone notices. An MFA bypass slots perfectly into that workflow. The attacker sprays or buys credentials, logs in through the alternate path, and the VPN session looks like any other remote worker connecting from home.

That last point matters for detection. Exploitation of CVE-2026-19868 will not look like an exploit. There is no weird payload or crash, just a successful login. The signals you want are authentication logs on the firewall showing SSL VPN sessions that authenticated via local, LDAP, or RADIUS methods when your policy says everyone should be coming through SAML. Cross-reference VPN logins against your identity provider. A SonicWall session with no matching SAML assertion and MFA approval in Entra, Okta, or Duo logs at the same time is a red flag worth chasing. Look also for logins from hosting providers and VPS ranges, logins at odd hours for the user, and any service or admin accounts establishing VPN sessions at all.

What to do right now

Patching comes first. Get every Gen7 and Gen8 appliance onto the fixed firmware, prioritizing anything with SSL VPN exposed to the internet, which in practice is most of them. Take a configuration backup before upgrading, because SonicOS upgrades occasionally like to keep things interesting.

While you are in there, do the configuration hygiene that would have blunted this bug in the first place. If SAML is your intended authentication path, remove or disable the alternate methods for SSL VPN users. Strip local user accounts down to a break-glass admin with a long random password stored in your vault. If LDAP or RADIUS has to stay for other features, make sure SSL VPN group membership is not granted through those paths. Restrict SSL VPN and management access by source geography or IP where the business allows it, and never leave the management interface open to the internet.

Then assume someone might already have used this. Reset passwords for accounts that can reach the SSL VPN, prioritizing anyone whose credentials have shown up in breach or infostealer data. Review VPN session history going back at least 30 days for the anomalies described above. If you find sessions you cannot explain, treat it as an incident and look for the usual follow-on activity, including new local admin accounts, remote management tools that nobody installed, and unusual traffic toward backup servers and hypervisors.

Finally, a broader lesson. MFA on a VPN is only as strong as the weakest way the appliance will accept a login. Every edge device that supports multiple authentication sources should be audited so that the strong path is the only path. Attackers have figured that out, and so should we.

If an IT provider manages your systems

If your office connects remotely through a SonicWall firewall, this flaw lets someone with a stolen password skip the MFA prompt you rely on. CISA lists it as exploited in real attacks.

• Are our SonicWall firewalls patched for CVE-2026-19868, with any Gen7 units on 7.3.4-7013 or newer?
• Besides SAML sign-on, does our SSL VPN still accept local, LDAP, or RADIUS logins, and can those be turned off?
• Have you checked the last 30 days of VPN logins for sessions that had no matching MFA approval?

A good answer names the firmware version, confirms SAML is the only way in, and describes a finished log review. If they find VPN sessions nobody can explain, treat it as a possible break-in and call in incident response right away.

If you are an IT provider yourself, see how we partner with MSPs.