SonicWall SonicOS SSLVPN Use of Single-factor Authentication Vulnerability

🚨SEVERITY: UNKNOWNSecurity Advisory

TL;DR 📌

  • SonicWall SonicOS SSLVPN contains a use of single-factor authentication vulnerability that may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls. Successful exploitation may also bypass SAML-enforced multi-factor authentication (MFA).
  • Listed in CISA KEV (2026-11-06) — this is being exploited in the wild.
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2026-19868.

What it is

CVE-2026-19868 affects the SSLVPN service in SonicWall SonicOS. The underlying issue is an authentication enforcement failure: the SSLVPN service does not correctly tie session authentication to the method an administrator has configured as mandatory.

In practice, this means a user who holds valid credentials for an alternate authentication method can authenticate through that method instead of the SAML path an organisation has set up. Where SAML is being used specifically to enforce multi-factor authentication, this allows that MFA requirement to be bypassed entirely — the attacker completes authentication using a single factor (the alternate credential) rather than the SAML/MFA flow administrators intended to be mandatory.

The access path is the SSLVPN service itself, reachable wherever that service is exposed. This is a credential-based bypass of a control, not a credential-free vulnerability: an attacker still needs a working set of valid alternate-method credentials to exploit it. The outcome is session establishment on the SSLVPN without having satisfied the MFA policy that SAML was meant to enforce.

The CVE is listed in CISA’s Known Exploited Vulnerabilities catalogue, added on 2026-11-06, meaning it is known to be exploited.

What to do

  • Check whether your SonicOS SSLVPN deployment uses SAML as the sole mechanism for enforcing MFA, and whether any alternate authentication methods (e.g. local or other non-SAML methods) remain enabled alongside it — if so, those alternate methods are the bypass route.
  • Consult the SonicWall advisory for this CVE for fixed SonicOS releases and apply them; no fixed version is stated here, so do not assume a specific build is safe without checking directly.
  • Where alternate authentication methods are not strictly required, disable them for SSLVPN so SAML is the only path, removing the bypass option even before patching.
  • Given this CVE is in CISA KEV, treat it as a priority patching and review item rather than routine maintenance — audit SSLVPN authentication logs for sessions that did not traverse the SAML/MFA flow.
  • Review SSLVPN exposure generally: restrict access to the service to known source addresses or a VPN concentrator where feasible, reducing the pool of users who could attempt the bypass.

For leadership 🧭

Executive summary. Attackers with a working alternate-method credential can log into SonicWall SSLVPN without passing through the SAML-based MFA your organisation relies on, and this is already being exploited according to CISA’s KEV listing. Because it affects an internet-facing remote access service, this needs priority handling this week, not at the next routine patch cycle.

Why it matters:

  • The bypass applies specifically to SonicOS SSLVPN, a remote-access service typically exposed to the internet for staff and partner connectivity.
  • Any alternate authentication method left enabled alongside SAML becomes the bypass route, so mixed-method configurations are the ones at risk, not SAML-only deployments.
  • This defeats the MFA policy organisations believed SAML was enforcing, meaning a single valid credential set is enough to establish a session.
  • CISA added this CVE to its Known Exploited Vulnerabilities catalogue on 2026-11-06, so active exploitation is confirmed rather than theoretical.

Now / Next / Later:

  • Now: Check your SonicOS SSLVPN configuration for any alternate (non-SAML) authentication methods still enabled alongside SAML, and disable them immediately if not strictly required.
  • Next: Apply the SonicWall fixed SonicOS release for this CVE once confirmed via the vendor advisory, and audit SSLVPN authentication logs for sessions that did not traverse the SAML/MFA flow.
  • Later: Restrict SSLVPN access to known source addresses or a VPN concentrator, and enforce SAML as the sole authentication path for remote access going forward.

Source