MFA on your SonicWall VPN? Not if a second path stays open

CVE-2026-19868 in SonicWall SSL-VPN bypasses SAML-enforced MFA via an alternate login method. CISA listed it in KEV. Patch now.

Your MFA dashboard reads 100 percent. Every employee gets a push or a code. The VPN runs through SAML, the modern way to force login through a cloud identity provider. On paper, the door is locked. But what if your SonicWall firewall still allows a second login method? Then someone with an old local password can walk around that MFA entirely.

That is exactly what CVE-2026-19868 does. SonicWall shipped a patch on 6 November. The same day, CISA, the US cybersecurity agency, added it to the KEV catalogue: the list of vulnerabilities with confirmed active exploitation. US federal agencies have until 20 November. Belgian and European SMEs will not get a letter from Washington. They do get the same attackers.

What's going on

In the SSL VPN of SonicOS, the software that runs on SonicWall firewalls, authentication enforcement is flawed. According to SonicWall, a user with valid credentials for an alternate authentication method can bypass SAML controls, including SAML-enforced multi-factor authentication. The issue only applies when SAML login is enabled for the VPN. Without SAML, this CVE is not your problem. With SAML and a second path beside it, it is.

Severity: CVSS 7.1 from SonicWall, 7.5 from CISA-ADP. That is "high", not a nine or a ten. It is still enough to sidestep the protection you thought you had. SonicWall is investigating a report of possible exploitation; no attack details have been shared. SecurityWeek and the CISA alert line up: patched, listed in KEV, no public attack detail.

Affected: Gen7 TZ, NSa, NSsp and NSv on SonicOS 7.3.3-7015 or older, and Gen8 TZ, NSa and NSv on 8.2.2-8015 or older. Fixed in 7.3.4-7013 and 8.2.3-8015. There is no workaround. Upgrading is the only path.

The same advisory covers six other flaws, including two CVSS 8.8 issues in the management interface and pre-authentication denial-of-service bugs in SSL VPN and TACACS+. Those are not reported as exploited. CVE-2026-19868 comes first.

Why this belongs in the boardroom

MFA feels like a finished project. The dashboard is green, the auditor is happy, the insurer asks for it. But MFA only protects the path where it is actually enforced. Leave a local account, LDAP or another method open next to SAML, and "MFA on" is a feeling, not a fact.

For an SME, the SonicWall is often the gateway for remote work, vendors and the MSP. Whoever gets through is on the network. Under NIS2, boards must show they manage risks like this. Leaving a known, actively exploited VPN flaw open is hard to defend. As we wrote about the Barracuda mail gateway flaw: patch management is not IT housekeeping. It is liability.

Through the attacker's eyes

At XPOSE, we think like the other side. What follows are scenarios, not a reconstruction of an attack and certainly not a how-to.

They hunt the weakest path, not the prettiest one. An attacker does not check whether your SAML flow is correct. They look for a path where MFA never fires. A leftover local VPN account, or an old LDAP binding nobody uses anymore, becomes the front door. Your MFA dashboard stays cheerfully at 100 percent.

Old credentials are gold. Former employees, a shared "vpn-test" account, a password from a breach three years ago: for this class of flaw you do not need a flashy exploit, you need a valid password on the wrong path. Those sit around more often than companies like to admit.

The firewall is trusted, so nobody watches. As with other security appliances we have covered, the VPN gateway enjoys default trust. Logs are rarely filtered for "login outside SAML". A successful login via a method that policy says should not exist therefore goes unnoticed.

One MSP, many clients. Plenty of SMEs have their SonicWall run by a partner. The same configuration habit, the same alternate method left open, across dozens of customers. For an attacker that is not a series of break-ins. It is one hunt, repeated.

The patch does not evict anyone. Updating closes the door. It says nothing about who is already inside. KEV means someone has already used this. Review VPN logs for logins that did not go through SAML, and for accounts you do not recognise.

What to do today

1. Upgrade SonicOS to 7.3.4-7013 or later (Gen7) or 8.2.3-8015 or later (Gen8). No workaround, so this is step one.
2. Disable alternate VPN login methods if SAML with MFA is the intent. One path. No "emergency" exceptions that have been open for years.
3. Take the management interface off the internet. Reachable only from trusted networks. Have someone check what of your environment is publicly visible.
4. Search VPN logs for logins outside SAML, for accounts that should no longer exist, and for successful logins around the disclosure date.
5. Ask your MSP in writing: which SonicOS version is running, when it was patched, which login methods are enabled, and who still has local VPN accounts.
6. Revisit vendor access. Permanent VPN accounts for installers or software vendors without MFA are exactly the kind of second path this flaw turns on.

Final thoughts

MFA is not a shield you hang up and forget. It is only as strong as the weakest login path beside it. CVE-2026-19868 makes that painfully concrete for anyone running SonicWall SSL VPN with SAML: a locked front door, and a side entrance without a lock. The patch is out. Use it.

XPOSE Security tests your environment the way real APT attackers would: from the VPN method left "temporarily" open to the management interface that turned out to be online. Better we find it than they do. Get in touch and strengthen your security posture structurally with our CISO as a Service.