“MFA was enabled,” the configuration logs claimed, but the multi-factor prompt never appeared at the VPN entrance. This is the core of CVE-2026-19868, a flaw in SonicWall’s SSL-VPN authentication enforcement that allows attackers with valid credentials for a non-SAML method to bypass SAML checks entirely. The multi-factor authentication that SAML is supposed to enforce is skipped along with it, leaving a gap between the security policy administrators expect and the checks actually applied.
The Authentication Path That Slipped Through
The technical reality is not that the Multi-Factor Authentication mechanism itself is broken. Rather, the procedure where MFA should have been requested was bypassed. SonicWall’s advisory, SNWLID-2026-0014, clarifies that the vulnerability affects the SonicOS SSLVPN interface only when SAML is enabled for SSLVPN login. In these environments, a separate authentication path remains active. If an attacker holds valid credentials for this alternate method, they can log in without passing through the SAML controls.
Exploitation is not a zero-credential attack. The attacker needs valid credentials for an alternate authentication method, such as an old local account or leaked credentials. However, if even one such account remains in the system, it becomes the key to bypassing the MFA wall. The flaw is classified as CWE-308 (Use of Single-factor Authentication) with a CVSS 3.1 score of 7.1 (High). The vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, indicating that while the attack complexity is high, the impact on confidentiality is significant once access is gained.
Why It Is Being Targeted Now
The urgency stems from the fact that SonicWall’s PSIRT stated it investigated reports indicating the possibility of exploitation of this vulnerability. CISA added CVE-2026-19868 to its Known Exploited Vulnerabilities (KEV) catalog on November 6, 2026, the same day the patch was released. This simultaneous listing signals active exploitation rather than speculative risk. For US federal agencies, the compliance deadline is November 20, 2026. The detail that matters here is that the KEV listing confirms the flaw is in the wild, not just on a theoretical radar.
SonicWall strongly urges customers to upgrade promptly. The company has not disclosed specifics on attackers, victims, attack methods, or the scale of the activity as of November 8. While the exploitation warning raises urgency, the supplied details do not identify specific ransomware campaigns or victim numbers. Describing a confirmed widespread campaign would go beyond the available evidence, but the patch was released because the threat is real.
Which Firewalls Are Exposed
The affected systems include Gen 7 firewalls (TZ, NSa, NSsp, NSv) running SonicOS 7.3.3-7015 or earlier, and Gen 8 firewalls (TZ, NSa, NSv) running 8.2.2-8015 or earlier. Patched versions are SonicOS 7.3.4-7013 for Gen 7 and 8.2.3-8015 for Gen 8. Gen 6 and earlier firewalls are unsupported and will not receive fixes. The vulnerability was reported by Ryan Harris of The Electronic Office, and no workarounds are listed in the advisory. The only countermeasure is to upgrade to the patched version.
Administrators must confirm their appliance generation and install the matching fixed release. The same advisory also patches six other vulnerabilities, including two critical flaws in the management interface with CVSS scores of 8.8. These are CVE-2026-107155 (improper cross-domain policy) and CVE-2026-107154 (session validation dependent on IP address). There is also an SSL-VPN pre-authentication heap buffer overflow (CVE-2026-82308, 7.5), two TACACS+ authentication client issues (CVE-2026-77708/77709, 5.9 each), and a weak password hash in virtual appliances (CVE-2026-19703, 5.2). Upgrading to the fixed release addresses all of these at once.
Real-World Risks and Blind Spots
The easiest thing to overlook is that having MFA implemented is not a basis for peace of mind if it is only applied to one authentication path. MFA functions when it is incorporated into the SAML authentication flow. If an authentication method other than SAML remains for SSLVPN login, MFA will not be requested for that path. Even if MFA is enforced on the Identity Provider side, any other entrance in the firewall’s authentication settings is outside the IdP’s management. This creates a blind spot where administrators assume MFA is enforced globally, when it is actually only applied to the SAML path.
In practice, this means an attacker using leaked credentials or an old local account can bypass the MFA checks entirely. The risk is heightened because these accounts often persist in enterprise environments for legacy reasons or are forgotten after employee departures. The flaw highlights a common configuration error: assuming that enabling SAML secures all login paths, when in reality, other methods may remain active and unchecked.
How This Differs From Past Flaws
This vulnerability is distinct from CVE-2024-53704, a previous SonicWall SSL-VPN flaw that allowed session hijacking without credentials. CVE-2026-19868 requires valid credentials for an alternate method, making it a different class of threat. The 2024 flaw was a login bypass that required no account, whereas this one exploits a misconfigured authentication flow to skip SAML and MFA. The session-hijacking behavior of the older flaw should not be treated as evidence of how this newly disclosed issue works.
The difference matters for defense. For CVE-2024-53704, the fix was about securing the session. For CVE-2026-19868, the fix is about ensuring that all authentication paths are subject to the same security controls. The technical reality is that a single unchecked path can undermine the entire security posture if it allows bypassing the primary identity verification mechanism.
What Admins Must Check Now
Administrators should review enabled authentication methods and confirm their appliance generation. If SAML is enabled for SSLVPN login, the environment is affected. If SAML is not used, the device is not subject to this specific CVE. The first step is to take inventory of the authentication methods available for SSLVPN. Check if local users or other authentication methods are enabled in addition to SAML. If unused authentication methods or local accounts of unknown origin remain, disable them.
Next, check SSLVPN login records for successful logins that did not go through SAML, or logins from suspicious times or sources. Because this is a vulnerability listed in the KEV, checking past logins is essential. Administrators should also handle credentials that may have been leaked. If there is a risk that credentials usable with other authentication methods have been leaked, change the passwords for the relevant accounts and disable unused accounts. Review the scope of MFA application for each authentication path to ensure that “requiring MFA for all SSLVPN login paths” is actually configured, not just “enforcing MFA at the IdP.”
Finally, check if any Gen 6 or older firewalls remain in the network. No patches will be released for Gen 6 or older. If any remain, a migration plan to Gen 8 is necessary. The deadline for US federal agencies is November 20, 2026, but for general companies, the correct interpretation is to upgrade immediately now that a patch is out because it is already being targeted. The patch is available now, and the risk is active.
Sources
- "MFA was enabled," but it wasn't asked for at the VPN entrance—SonicWall CVE-2026-19868 and the authentication loophole that bypasses SAML｜PhoenixAutomation
- SonicWall Warns of Potential In-the-Wild Exploitation of SSLVPN Flaw That Bypasses MFA
Photo: Petter Lagson / Unsplash (Unsplash License)
