SonicWall SSLVPN SAML Bypass, Exploited in the Wild (CVE-2026-19868)

TL;DR

• A SonicOS SSLVPN flaw lets an account with valid credentials for an alternate authentication method skip the SAML policy, including the multi-factor authentication enforced through SAML. SonicWall published CVE-2026-19868 on 2026-11-06.
• Gen7 firewalls at 7.3.3-7015 or earlier and Gen8 firewalls at 8.2.2-8015 or earlier are affected when SAML is enabled for SSLVPN logins. The fixed builds are 7.3.4-7013 and 8.2.3-8015.
• SonicWall rates the flaw CVSS v3.1 7.1 High, and the CISA ADP carries 7.5. SonicWall investigated a report indicating potential exploitation, and CISA added the CVE to the Known Exploited Vulnerabilities catalog on 2026-11-06 with a 2026-11-20 deadline.
• Upgrade to 7.3.4-7013 or 8.2.3-8015; SonicWall lists no workaround. Until then, review which accounts can authenticate to the SSLVPN by a non-SAML method, as "How do I fix it?" explains.

Am I affected?

You need all of these conditions to be exposed to CVE-2026-19868:

• The firewall runs SonicOS Gen7 at 7.3.3-7015 or earlier, or Gen8 at 8.2.2-8015 or earlier.
• The SSLVPN service is enabled and reachable from the network where the attacker operates.
• SAML is enabled for SSLVPN logins. SonicWall states the flaw "ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins".
• At least one account can authenticate through an alternate authentication method. The attacker needs valid credentials for that account, as the advisory states.

The advisory covers two platform lines and a long list of models.

• Gen7 hardware: TZ 270, 370, 470, 570 and 670; NSa 2700 through 6700; NSsp 10700 through 15700.
• Gen7 NSv: NSv 270, 470 and 870.
• Gen8 hardware: TZ 80, 280, 380, 480, 580 and 680; NSa 2800 through 5800.
• Gen8 NSv: NSv XS, S, M and L.

The advisory also fixes six other SonicOS flaws in the same builds. This post is about CVE-2026-19868, the only one of the seven that CISA has added to the KEV catalog. The exploited flaw is not the highest-scored issue in its own advisory: two management-interface flaws are rated 8.8 and the SSL-VPN heap overflow is rated 7.5. The KEV listing, not the score, is what makes it urgent.

Check the running firmware before anything else. At the SonicOS command line, show version prints the version string. In the web interface, System > Status shows the same string. The version must be compared with the fixed build for the platform line, not with the newest release in general.

Then check the SSLVPN configuration. In the SSLVPN authentication settings, confirm whether SAML is enabled for VPN logins. If it is not, this CVE does not apply to that configuration, even on an affected build. The other six flaws in the advisory have their own conditions, so an upgrade is still warranted.

Finally, list the accounts and authentication methods the SSLVPN accepts. The advisory does not name which alternate methods reach the flaw. Treat every enabled method other than SAML as a possible path and every account that can use it as a possible source of valid credentials.

How do I fix it?

1. Back up the firewall configuration and record the current firmware version, so the upgrade can be rolled back.
2. Download the fixed build for the platform line from MySonicWall: 7.3.4-7013 or later for Gen7, and 8.2.3-8015 or later for Gen8. SonicWall publishes the fixed platforms and versions in the advisory's Fixed Software table.
3. Install the firmware on each firewall and confirm the new version after the reboot. For an NSv virtual appliance, upgrade or redeploy it with the same fixed build.
4. Confirm that the SSLVPN still uses SAML for the accounts that should use it, and that no unintended alternate method remains enabled.

The same upgrade fixes six companion flaws in SNWLID-2026-0014.

• Two 8.8 management-interface flaws, CVE-2026-107155 and CVE-2026-107154.
• A 7.5 pre-authentication heap overflow in the SSL-VPN service, CVE-2026-82308.
• Two 5.9 pre-authentication overflows in the TACACS+ client, CVE-2026-77708 and CVE-2026-77709.
• A 5.2 weak password-hashing flaw on virtual appliances, CVE-2026-19703.

Only CVE-2026-19868 has an exploitation report and a KEV entry.

SonicWall lists no workaround. The steps in this section reduce exposure until the upgrade is done, but they do not correct the authentication enforcement flaw.

1. Remove or disable SSLVPN accounts that can authenticate by a non-SAML method. This removes those users' VPN access, so keep an administrative path that does not depend on the SSLVPN.
2. Limit the SSLVPN to source addresses you control, such as a corporate egress range or a management network. This reduces the population that can reach the login page, but the flaw remains reachable from any allowed address.
3. Review the SSLVPN authentication logs for successful logins that used a non-SAML method. A login for an account that was supposed to use SAML is a lead, not proof of compromise.

None of these steps is a substitute for the fixed build. The vendor's remediation is the firmware upgrade.

What is the root cause?

The SSLVPN gateway does not enforce the SAML policy for an account that can authenticate through another method. Such a login completes without the SAML assertion. It also skips the MFA that SAML enforces.

SonicOS can authenticate SSLVPN users through more than one method. An administrator who enables SAML expects the gateway to require the SAML flow and the identity provider's MFA for every VPN login. The flaw is in that enforcement. When an account presents valid credentials for an alternate method, the gateway accepts that method as sufficient. The SAML check is not applied, so the login proceeds on the alternate method alone.

SonicWall assigns CWE-308, Use of Single-Factor Authentication, to the flaw. That weakness describes the result rather than a single line of code. One authentication factor satisfies the gateway: the credential for the alternate method. That is enough even though the administrator configured SAML and its MFA. The CVSS scope is changed, because the bypass crosses the authentication boundary the administrator configured.

SonicWall publishes no source code or patch diff for SonicOS. The advisory names the precondition, the affected builds and the impact. It does not name the code path, the alternate method, or the request sequence.

The exact branch in the authentication code therefore cannot be reconstructed from public information. What is public is the boundary of the bug: SAML must be enabled for SSLVPN logins, and the attacker must hold valid credentials for an alternate method.

How is it exploited?

The attack turns a valid password for an alternate method into a VPN session that never satisfies the SAML policy or its MFA. The advisory describes the mechanism but publishes no request sequence, so the steps in this list follow its wording and the CVE record:

1. The attacker finds an internet-facing SonicOS SSLVPN with SAML enabled for VPN logins.
2. The attacker holds valid credentials for an account that can authenticate through an alternate method. The advisory does not name which methods are accepted on a vulnerable configuration.
3. The attacker authenticates to the SSLVPN through that alternate method instead of the SAML flow.
4. The gateway accepts the login without requiring the SAML assertion. The SAML-enforced MFA does not run, because the session never reaches the SAML step.
5. The attacker receives a VPN session with the account's permissions and can reach the internal resources that account is allowed to reach.
6. The session can be used like any other VPN session, with the same logging and the same access controls that apply to that account.

This is an MFA bypass for a stolen, reused or otherwise obtained password. It is not an unauthenticated entry into the firewall. The attacker still needs a valid credential for an account that can use an alternate method. That distinction matters when you assess exposure: the population at risk is every account that can bypass the SAML policy, not every internet user.

CISA added the CVE to KEV on 2026-11-06, which records active exploitation. SonicWall says it investigated a report indicating potential exploitation. Neither source names a victim, a date, an actor or a source address. No public proof of concept or request sequence is available, so these steps cannot be replayed from public information alone.

How does the attack flow?

A valid password for an alternate method reaches the SSLVPN, the gateway skips the SAML policy and its MFA, and the attacker gets a VPN session with that account's access.

What can an attacker do?

The attacker gets a VPN session as the account whose alternate-method credentials were used, with that account's permissions. The direct impact is access to the internal networks and services the account is authorized to reach.

SonicWall rates CVE-2026-19868 CVSS v3.1 7.1 High, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N. The CISA ADP in the CVE record carries 7.5, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N. The two vectors differ on privileges required: the vendor assumes a valid account, and the CISA ADP does not. Both record High confidentiality impact, Low integrity impact and no availability impact. That matches a read-oriented VPN foothold rather than a code-execution bug.

Every condition from "Am I affected?" applies in full:

• The firewall is an affected Gen7 or Gen8 build.
• The SSLVPN is reachable from the attacker's network.
• SAML is enabled for SSLVPN logins.
• The attacker holds valid credentials for an account that can authenticate through an alternate method.

The advisory describes no way to exceed the account's VPN authorization through this flaw. A low-privilege account gives a low-privilege tunnel; a privileged or broadly authorized account gives much more. The advisory does not describe account creation, code execution or privilege escalation on the firewall itself, and neither does the CVE record. Treat those as out of scope for this CVE rather than as demonstrated impact.

The exposure is largest where the SSLVPN is the MFA boundary for a workforce. Any password that would otherwise be stopped by SAML MFA becomes enough to open a VPN session. That is the scenario the KEV listing makes urgent, and it is why the fixed build, not a detection rule, is the primary control.

Why does the fix work?

The fixed builds close the enforcement gap, so a login through an alternate method can no longer satisfy the SSLVPN when SAML is configured for VPN logins. SonicWall does not publish the code change or a patch diff, so the completeness of the fix rests on the vendor's statement that 7.3.4-7013 and 8.2.3-8015 contain it.

The advisory lists the same fixed builds for the whole seven-CVE batch, and it lists no workaround. That makes the upgrade the only vendor-supported remediation. The operational steps in "How do I fix it?" reduce who can reach the alternate path, but they leave the enforcement flaw in place.

If you operate a virtual appliance, confirm that the NSv image is rebuilt or upgraded to the fixed build. A configuration backup restored onto an old image reintroduces the flaw.

How do I check if I was compromised?

SonicWall has not published indicators of compromise, a victim count or a request signature. The checks in this section look for the effect of the flaw rather than for a known payload.

Start with the SSLVPN authentication records on the firewall or in the syslog collector. Look for successful logins by accounts that are supposed to use SAML, and compare the authentication method recorded for each login with the method the account is supposed to use. A successful login for a SAML-only account that records any other method is the pattern this flaw would produce.

Then check what the session did. Review the source addresses and times of those logins against the account's normal pattern. Look for internal hosts or services the account does not normally reach, and for sessions that began outside the account owner's working hours or country.

Check the account inventory for changes around the same period. New local accounts, newly enabled alternate authentication methods and new SSLVPN authorizations are all worth investigating.

The KEV entry links CISA's forensic triage requirements under Binding Operational Directive 26-04. That guidance is the reference for the evidence to preserve, even if you are not a federal agency.

An attempt that fails leaves no special trace. A successful login may look like a normal one in a log that does not record the authentication method. If you cannot rule out a login, treat the account as compromised. Reset its credentials and review what it could reach. Rebuild the firewall from a known-good configuration if the device itself is suspect.

Timeline

• 2026-11-06: SonicWall publishes SNWLID-2026-0014 and CVE-2026-19868. The advisory says SonicWall PSIRT investigated a report indicating potential exploitation.
• 2026-11-06: CISA adds CVE-2026-19868 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of 2026-11-20.
• 2026-11-20: The federal remediation deadline for CVE-2026-19868.

FAQ

Does this affect SonicWall SMA1000 appliances?

No. CVE-2026-19868 is a SonicOS flaw in the Gen7 and Gen8 firewall and NSv lines. The SMA1000 is a separate remote-access product line, and its 2026 issues have their own advisories and fixes. A SonicWall estate can contain both, so check each product against its own advisory rather than against this build table.

Can an attacker exploit it without any credentials?

No. The advisory requires valid credentials for an alternate authentication method. The flaw removes the SAML and MFA step for that account; it does not remove the password step. An internet user with no account on the firewall or its identity sources cannot use this path.

Is it exploitable when SAML is not enabled?

No. SonicWall limits the flaw to SSLVPN services where SAML is enabled for VPN logins. That does not make the other six flaws in the advisory harmless, and an affected build should still be upgraded.

Is there a workaround if I cannot upgrade today?

SonicWall lists none. Removing alternate-method accounts from the SSLVPN and restricting the service to trusted source addresses reduce exposure, but they do not fix the enforcement gap. The fixed firmware is the remediation.

Is CVE-2026-19868 in CISA KEV?

Yes. CISA added it on 2026-11-06 with a federal due date of 2026-11-20. That listing records active exploitation, and it is the reason this post leads with the upgrade rather than with detection.

What about the other six CVEs in the same advisory?

They are fixed in the same builds.

• Two management-interface flaws are rated 8.8.
• The SSL-VPN heap overflow is rated 7.5.
• The two TACACS+ overflows are rated 5.9 each.
• The weak password-hashing flaw is rated 5.2.

Only CVE-2026-19868 has an exploitation report and a KEV entry.

Find exposed SonicWall SSLVPN gateways with Ostorlab

Ostorlab's attack surface discovery inventories internet-facing hosts and the services they expose. Use it to list the SonicWall gateways that answer on their management and VPN interfaces, then check their firmware.

References

• SonicWall PSIRT advisory SNWLID-2026-0014, "SonicWall SonicOS Affected By Multiple Vulnerabilities", published 2026-11-06, with the affected platforms, the fixed versions, the seven CVE identifiers and the exploitation statement: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0014 (checked November 7, 2026)
• CVE-2026-19868 record, SonicWall CNA, published 2026-11-06, CWE-308, the affected versions and the CISA ADP metric and KEV block: https://www.cve.org/CVERecord?id=CVE-2026-19868 (checked November 7, 2026)
• CISA Known Exploited Vulnerabilities catalog, CVE-2026-19868 added 2026-11-06 with a due date of 2026-11-20: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked November 7, 2026)
• BleepingComputer, "SonicWall warns of new SSL-VPN MFA bypass flaw exploited in attacks", 2026-11-06, the vendor's exploitation statement, the fixed versions and the reporter credit: https://www.bleepingcomputer.com/news/security/sonicwall-warns-of-new-ssl-vpn-mfa-bypass-flaw-exploited-in-attacks/ (checked November 7, 2026)
• CWE-308, Use of Single-Factor Authentication, the weakness SonicWall assigns to the flaw: https://cwe.mitre.org/data/definitions/308.html (checked November 7, 2026)
• CISA Binding Operational Directive 26-04, the forensic triage requirements referenced by the KEV entry: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk (checked November 7, 2026)