SonicWall SSLVPN Flaw May Bypass SAML MFA: Is Your Firewall at Risk?

At a glance (as of 6 November 2026)

Information is still developing. This page was drafted on the day CISA added CVE-2026-19868 to its Known Exploited Vulnerabilities (KEV) catalogue. Fixed firmware builds must be confirmed from SonicWall's current advisory before upgrading; treat other build numbers as leads, not a definitive patch list.

• Vendor and product: SonicWall, SonicOS, SSLVPN service. Vendor advisory SNWLID-2026-0014.
• The problem: an authentication enforcement flaw, classed by CISA as use of single-factor authentication (CWE-308). A user with valid credentials for an alternate authentication method may be able to bypass SAML authentication controls, and potentially SAML-enforced MFA.
• Exploitation: CISA lists it as known to be exploited. The Canadian Centre for Cyber Security says SonicWall reports exploitation. Whether ransomware groups are using it is listed by CISA as unknown.
• Immediate action: confirm whether SSLVPN is enabled on your SonicWall, check your firmware against the vendor advisory, restrict SSLVPN exposure if you cannot patch yet, and review recent SSLVPN logins.

Latest confirmed position

CISA's KEV entry is titled "SonicWall SonicOS SSLVPN Use of Single-factor Authentication Vulnerability". It was added on 6 November 2026 with a due date of 20 November 2026 for US federal agencies. The required action is to apply SonicWall's mitigations and, if none are available, to stop using the product. That deadline is binding on US federal bodies only, but it is a useful signal of how seriously CISA rates the risk.

The Canadian Centre for Cyber Security published alert AV26-1133 the same day. It repeats that SonicWall reports exploitation and advises administrators to review SonicWall's advisory and apply updates as they become available. The phrase "as they become available" matters: it suggests fixes may not yet be published for every affected branch. Read SonicWall's advisory for the current position on your hardware or virtual appliance.

The NVD entry for the CVE was published on 6 November 2026 and, the cited NVD record did not provide a confirmed severity score. Some third-party trackers show a CVSS 3.1 score of 7.5 attributed to CISA, but that number is not corroborated by the primary references cited here. Severity here matters less than the exploitation status.

Who should check

You are in scope if you run a SonicWall firewall on SonicOS and have the SSLVPN service enabled for remote users. The risk is greatest where SSLVPN is reachable from the internet and where you rely on SAML (single sign-on with an identity provider, usually with MFA) as the thing that protects remote access.

Affected versions are reported inconsistently, so do not rely on a single figure. Aggregated NVD data indicates SonicOS 7.3.3-7015 and older, and 8.2.2-8015 and older. The Canadian Cyber Centre lists builds earlier than 7.3.4-7013 and earlier than 8.2.2-8015. The ranges differ at the edges, and SonicWall's release notes index for the 7.3 line that we checked lists a 7.3.4-7015 build but not 7.3.4-7013. Until you have read SNWLID-2026-0014 yourself, assume that a build on either branch could be affected if it is not clearly listed as fixed.

If you do not use SSLVPN, this particular flaw is much less relevant to you, but confirm that rather than assume it. Firewalls are often inherited with services nobody remembers enabling.

Understand the risk

The description is short, so here is the sensible reading. SAML lets your firewall hand login over to an identity provider such as your Microsoft 365 or Google tenant, which is where MFA is normally enforced. The flaw is described as letting someone with valid credentials for a different authentication method bypass those SAML controls. In practice that suggests an attacker who has already obtained a password (phished, reused or leaked) for an account that also works through another method might sign in to the VPN without meeting the MFA requirement. That is our interpretation of the short description, not a statement from SonicWall, so confirm the exact conditions in the advisory.

The attacker still needs valid credentials, which is a real limit. But stolen passwords are the most common starting point for remote access attacks, and MFA exists precisely to blunt that. A VPN login that silently skips MFA also gives access inside your network, so the potential impact is broad even though the flaw is not a pure unauthenticated takeover.

Exploitation is reported by CISA's KEV listing and, according to the Canadian Cyber Centre, by SonicWall. Neither source names victims, and the cited sources identify no victims. A KEV entry tells you attacks have been seen somewhere, not that your firewall has been compromised.

What to do now

These steps are in priority order. The first three are read-only and need administrator access to the SonicWall management interface. Menu paths vary between SonicOS 7 and 8, so use the controls shown on your current firmware rather than relying on a single set of labels. If you are not the person who manages the firewall, send this page to whoever is, or to your IT provider.

1. Establish whether SSLVPN is switched on and reachable from the internet. If it is not enabled, note that and move on to checking the firmware regardless, since other SonicOS advisories are published regularly.
2. Record the exact firmware build running on each SonicWall and compare it with the affected and fixed lists in SonicWall advisory SNWLID-2026-0014. This is the step that decides whether you are exposed, so use the vendor page rather than this article.
3. Check how SSLVPN users authenticate. If remote access is meant to be protected by SAML with MFA, find out whether local accounts or other authentication methods (such as LDAP or RADIUS) are also permitted for SSLVPN. Those alternate routes are the ones the vulnerability description points to. Do not remove an authentication method on a production firewall without a plan: you can lock out legitimate remote staff. If the SonicWall advisory describes a configuration mitigation, follow that. If it does not, ask SonicWall support before changing authentication settings.
4. If you cannot patch promptly and remote access is not business-critical this week, consider temporarily restricting SSLVPN to known source addresses or disabling it. This is our engineering judgement, not a SonicWall-published workaround, and it will cut off remote users, so arrange another route for them first. CISA's own instruction for federal systems is to discontinue use of the product if vendor mitigations are unavailable. Afterwards, test from outside your network to confirm that the restriction behaves as you expect.
5. Review SSLVPN login records for the past few weeks. Look for logins from unfamiliar countries or addresses, logins at odd hours, accounts that normally sign in via SAML appearing through a different method, and many failed attempts followed by a success. Export or save the logs before you restart or upgrade the firewall, as logs may not survive.
6. Apply SonicWall's fixed firmware as soon as it is confirmed for your model, following SonicWall's upgrade guidance. Expect SSLVPN and general traffic to be interrupted during the reboot, so schedule a short window. Afterwards, check the running build in the management interface and confirm that a remote test user can sign in with SAML and MFA as intended.

Patch and recovery

Fixed build numbers need confirmation from SonicWall's current advisory. Sources suggest a 7.3.4-7013 build and an 8.2.2-8015 boundary may be relevant, but the sources disagree about exactly which side of those numbers is vulnerable, and the cited release information does not establish either boundary. Please verify against SonicWall's advisory and the release notes for your hardware generation before you upgrade.

Patching closes the door; it does not tell you whether someone already walked through it. If your log review shows suspicious SSLVPN logins, treat the affected accounts as compromised: reset their passwords, revoke active sessions at the identity provider, and check what those accounts accessed internally. The UK NCSC's guidance on responding to active exploitation is a good framework for deciding how far to go. If you find evidence of intrusion, consider bringing in incident response help rather than cleaning up alone.

Real-world reporting

Exploitation is reported by CISA's KEV catalogue and, via the Canadian Cyber Centre, by SonicWall. We have found no public statement from any organisation linking an incident to this specific CVE, and a KEV listing does not identify victims, so we name none. CISA lists use in ransomware campaigns as unknown. We will update this page if credible, specifically attributed reporting appears.