← Blog
SonicWallSSLVPNMFA BypassCISA KEV

SonicWall CVE-2026-19868: SSLVPN SAML MFA bypass, exploited and KEV-listed

SonicWall confirms possible exploitation of CVE-2026-19868, a SonicOS SSLVPN bug that bypasses SAML-enforced MFA. On CISA KEV, due Nov 20 — patch now.

Zero Hunt Research··7 min read

Published by Zero Hunt, an autonomous AI red team on an on-premise appliance running private AI: automated penetration testing for networks and infrastructure, black-box or gray-box, with a human approving every step that matters.

SonicWall published advisory SNWLID-2026-0014 on November 6, 2026, and buried inside a seven-CVE SonicOS bundle is the one that matters tonight: CVE-2026-19868, an authentication-enforcement flaw in the SonicOS SSLVPN service. The vendor's own text is blunt — "SonicWall PSIRT has investigated a report indicating potential exploitation of this vulnerability" — and CISA agreed fast enough to add it to the Known Exploited Vulnerabilities catalog the same day. The effect is the part that should move your evening: a user with valid credentials for an alternate authentication method can bypass the SAML controls on the VPN, and with them the SAML-enforced multi-factor authentication you thought was protecting remote access.

Developing story — first published 20:56 CET (19:56 UTC), November 6, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE CVE-2026-19868
Product / affected versions SonicOS SSLVPN · Gen7 (TZ, NSa, NSsp, NSv) 7.3.3-7015 and older · Gen8 (TZ, NSa, NSv) 8.2.2-8015 and older · only when SAML is enabled for SSLVPN logins
Fixed in Gen7 7.3.4-7013 and higher · Gen8 8.2.3-8015 and higher (SonicWall, November 6, 2026)
CVSS 7.1 HIGH · CVSS 3.1 · scored by SonicWall PSIRT · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N · NVD not yet scored (status Received)
Exploited in the wild Yes · SonicWall PSIRT investigated a report of potential exploitation; CISA KEV-listed
CISA KEV Added 2026-11-06; federal due date 2026-11-20 (BOD 26-04)
Public PoC None public as of 2026-11-06
Official advisory SNWLID-2026-0014

What CVE-2026-19868 actually breaks

SonicOS lets you point SSLVPN logins at SAML — the modern setup, where your identity provider owns the login and enforces MFA. CVE-2026-19868 is the gap between "SAML is configured" and "SAML is the only way in." Where an account also has credentials for an alternate authentication method, an attacker holding those credentials can authenticate through that path and never meet the SAML challenge. The classification is CWE-308, Use of single-factor authentication: the second factor exists on paper, but a side door reduces the login back to one factor.

The CVSS vector tells you who this is for. PR:L means the attacker needs some valid credential to start — this is not an unauthenticated internet drive-by. AC:H reflects the specific conditions (a SAML-enabled SSLVPN, an account reachable by an alternate method). But S:C — scope changed — and C:H are the honest part: once past the VPN, the attacker is inside, authenticated, and holding the keys to whatever that account can reach. SonicWall is explicit that the flaw "ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins." If you never turned on SAML for the VPN, this specific CVE is not your problem tonight — but six other CVEs in the same advisory are, including two unauthenticated SonicOS management-interface flaws rated CVSS 8.8.

This is a pattern, not a surprise

Treat tonight as the third act. In May 2026, Security Affairs reported ReliaQuest observing the first in-the-wild exploitation of CVE-2024-12802 — a different SonicWall MFA bypass where separate handling of Active Directory UPN and SAM account names let MFA be configured independently per login method, so attackers walked in via the alternate account name. In that case a firmware update alone did not fix it: the device passed the version check while the vulnerable LDAP configuration stayed in place, and ReliaQuest said as few as 13 brute-force attempts separated an attacker from a valid credential.

"The firewall is patched." — the version string says yes; the authentication logic says a side door is still open.

The reason attackers keep hammering this surface is in the numbers from the ransomware side. Arctic Wolf Labs tracked an Akira campaign deploying ransomware through SonicWall SSLVPN logins since late July 2025, as reported by Cyber Security News, tied by SonicWall to the 2024 flaw CVE-2024-40766 — with dwell times "often measured in hours, with some intrusions taking as little as 55 minutes." A VPN MFA bypass is not an abstract weakness. It is the first 55 minutes of a ransomware incident.

Remediation

1. Am I affected? In SonicOS, check the running firmware (Device / Dashboard → System status). You are affected if you run Gen7 at 7.3.3-7015 or older, or Gen8 at 8.2.2-8015 or older. Then check whether SAML is the configured authentication for SSLVPN (SSL VPN server/auth settings) — if SAML is not enabled for SSLVPN, CVE-2026-19868 does not apply to you, but the other advisory CVEs still do.

2. Patch — exact fixed versions. Gen7 firewalls and NSv: 7.3.4-7013 and higher. Gen8 firewalls and NSv: 8.2.3-8015 and higher. SonicWall lists no workaround for CVE-2026-19868 ("is_workaround_available: False"), so the update is the fix, not an option.

3. Can't patch this minute? Shrink the exposure. Restrict the SSLVPN portal to known source addresses or an allow-list while you schedule the firmware update; the fewer places the alternate-method login is reachable from, the smaller the window. Do not "fix" this by disabling SAML — that removes the MFA you are trying to protect. Reducing reachability is a holding action, not a substitute for the patch.

4. Hunt for compromise. SonicWall has not published CVE-2026-19868-specific indicators yet. As a starting point, the related SonicWall SSLVPN MFA-bypass work (CVE-2024-12802) surfaced VPN logins that completed a normal-looking MFA flow but were marked sess='CLI' — a sign of scripted authentication — alongside SonicOS Event IDs 238 and 1080, per the ReliaQuest reporting above. Map it to ATT&CK: External Remote Services (T1133) for the VPN entry and Valid Accounts: Domain Accounts (T1078.002) for the authenticated session. Review SSLVPN authentication logs for successful logins from VPS/hosting ASNs and for accounts reaching internal scanning within minutes of connecting.

5. Eradicate and verify. If you find a suspicious SSLVPN session, rotate the credentials for every account reachable by the alternate method, not just the one you caught, and terminate active VPN sessions. Then verify the fix the way an attacker would check it: confirm the firmware build and attempt an alternate-method login against a SAML-enforced account to prove the side door is closed. A clean version string is not proof.

What is not known yet

  • The scale and the actor. SonicWall cites "a report indicating potential exploitation"; CISA KEV records ransomware use as "Unknown." No attribution is confirmed.
  • NVD has not scored CVE-2026-19868 (status Received as of this writing); the 7.1 figure is SonicWall PSIRT's.
  • No public proof-of-concept exists as of November 6, 2026, and CVE-2026-19868-specific IOCs have not been published.
  • Whether, as with CVE-2024-12802, any devices will remain exploitable after the firmware update pending configuration changes.

We will update this post as the vendor and CISA publish more.

Proving the wall is really there

The trap in this CVE is the one SonicWall admins already lived through in May: a firewall that reports itself patched while an authentication side door stays open. A version-string scan cannot see that gap, because the gap is in the logic of how SSLVPN enforces identity across methods — not in a build number. The only way to know whether your SAML-enforced MFA is actually a wall is to try to walk past it with a valid alternate-method credential, the way this CVE's attacker does.

That is the case Zero Hunt is built for: an autonomous AI red team that runs on-premise on private AI, with a human in the loop for every action that matters. Pointed at your VPN in a gray-box campaign — authenticated, with the credentials a real attacker would phish or brute-force — its agents attempt the alternate-method login and the SAML bypass directly, rather than reading a firmware version and calling it safe. Every exploit is written per target and backtested in the AI Gym before it touches production, and every finding is signed at write time (Ed25519, hash-chained) so the "we confirmed the bypass is closed" evidence survives an audit.

When the fix lands, the question becomes which of the seven advisory CVEs to chase first. Zero Hunt's Remediation Advisor ranks by real exploitability — CISA KEV first (CVE-2026-19868 is now on it, due November 20 under BOD 26-04), then what the campaign actually exploited, then CVSS and EPSS — and hands back the exact fixed build with rollout and rollback notes, then re-verifies the fix with the same test that proved the hole. If you are weighing continuous validation of your perimeter, our automated penetration testing guide and the on-premise red team overview are the place to start. For the appliance side of the same vendor, see our earlier write-up on the SonicWall SMA1000 SSRF-to-RCE chain.

Every vulnerability CISA lists as exploited, with federal due dates: CISA KEV tracker →

Patching one CVE at a time? A CTEM program validates which exposures are actually exploitable before the next advisory: what CTEM is →

Is this exploitable in your environment?

Zero Hunt answers that on your own network: an autonomous AI red team on an on-premise appliance, running on private AI, black-box or gray-box, with a human approving every step that matters. Proof of what is exploitable, the fix, and signed evidence — no data leaves your perimeter.