SonicWall SonicOS CVE-2026-19868: SAML MFA Bypass Exploited, Patch Now

If your SonicWall firewall sends SSL VPN logins through SAML single sign-on so that your identity provider can enforce multi-factor authentication (MFA), patch it now. CVE-2026-19868 lets someone who holds valid credentials for a different login method on the same firewall skip the SAML step, and with it the MFA prompt. It affects SonicOS 7.3.3-7015 and older on Gen7 firewalls and 8.2.2-8015 and older on Gen8. The fixes are 7.3.4-7013 and 8.2.3-8015.

CISA lists this flaw as exploited in attacks. SonicWall's advisory SNWLID-2026-0014, published November 6, 2026, says its security team investigated a report of potential exploitation and urges customers to upgrade. The same day, CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog and gave US federal civilian agencies until November 20 to fix it. SonicWall lists no workaround. CISA's catalog entry marks ransomware use as unknown, and no public proof-of-concept code had been reported when we checked.

Who is exposed to CVE-2026-19868?

A SonicWall firewall is exposed when SAML authentication is turned on for SSL VPN logins and the firmware is at or below 7.3.3-7015 (Gen7) or 8.2.2-8015 (Gen8). SonicWall says the flaw affects the SSL VPN service only when SAML handles its logins. Firewalls that authenticate VPN users another way are outside this CVE.

That condition cuts both ways. Most SonicWall shops never set up SAML and can treat this as a routine upgrade. The organizations that did set it up tend to be the ones that moved VPN logins behind Entra ID, Okta or a similar identity provider specifically to get MFA in front of the firewall. CVE-2026-19868 lands on exactly the teams that believed their VPN was MFA-protected.

One version string needs care. Gen8 builds through 8.2.2-8015 are vulnerable, and the fix is 8.2.3-8015. The build numbers match and only the middle digit changes, so check the full string before closing the ticket. At least one government bulletin summarized the affected Gen8 range slightly differently, so take the version boundaries from the CVE record or SonicWall's advisory.

Why the MFA prompt can be skipped

SonicWall classifies the bug as CWE-308, use of single-factor authentication. The advisory gives the precondition: the attacker needs valid credentials for an alternate authentication method. When that is met, the SAML check and any MFA the identity provider enforces can be bypassed. SonicWall has not said which alternate methods apply or how the reported exploitation unfolded. The practical reading is that a password the firewall accepts through some path other than SAML can get a user onto the VPN without the second factor.

That framing matters because many firewalls still have other credentials on them after a SAML rollout. Typical leftovers are local admin and break-glass accounts, older LDAP or RADIUS users from before the move to single sign-on, and service accounts nobody retired. Each one is now a possible way in that skips MFA, and any of those passwords may already be in a breach dump or an infostealer log.

This is the second time in under two years that a SonicWall SSL VPN has let MFA be skipped through a side door. In March 2025, SonicWall's notice on CVE-2024-12802 explained that MFA could be configured independently for each login method. Because the firewall treated the two Active Directory name formats, UPN and SAM, as separate logins, the alternate name could avoid MFA. The bugs differ, but the lesson is the same: MFA that protects one login path does not stop a password that works on another. Credential-led VPN intrusions keep using this route. Ransomware crews have been reported walking through a Palo Alto VPN authentication bypass and using MFA seeds stolen from SonicWall's separate SMA appliances.

Severity scores differ depending on who calculated them. SonicWall rates the flaw 7.1 and its vector assumes the attacker already holds a low-privilege login. CISA's enrichment of the CVE record scores it 7.5 with no privileges required. Both put it in the High band, and neither number matters much once a CVE is in KEV.

Checking logins that never reached your identity provider

Patching closes the hole. It does not tell you whether anyone used it before you upgraded. The most useful check comes from how SAML works: every legitimate SSL VPN login on a SAML-configured firewall should line up with a sign-in at your identity provider for the same user a moment earlier. A firewall login with no matching identity provider sign-in deserves a closer look.

SonicOS 7 can log every successful SSL VPN login, but the event has to be enabled first. Its location, per SonicWall's login-monitoring guide:

Exposure check
  Running SonicOS firmware version              at or below 7.3.3-7015 (Gen7) / 8.2.2-8015 (Gen8)
  SSL VPN > Server Settings                      Authentication type = SAML  (only this configuration is affected)
Login events to enable and export
  Device > Log > Settings > Users > Group Authentication Access
    Event ID 1080   Successful SSLVPN User Login   priority Inform or Alert, Display Event in Log Monitor
    Event ID 263    Event User Logout              same settings
Correlate
  each event 1080 (user, source IP, time)  against  identity provider SAML sign-ins for the same user
  no matching sign-in within a few minutes = login that did not pass SAML or MFA

If those events were never enabled, or the firewall keeps no log history, the firewall alone cannot answer the question. In that case your identity provider's sign-in history and the VPN address pool's traffic logs are the next best evidence. Look for VPN-assigned addresses talking to internal hosts at times when no matching identity provider sign-in exists.

Upgrade first, then retire every non-SAML password

Here is the order we would follow on an affected firewall:

• Upgrade to 7.3.4-7013 or 8.2.3-8015 (or later). SonicWall offers no workaround, so the firmware is the fix. Federal agencies have until November 20.

• List every credential the firewall still accepts outside SAML. That means local users, LDAP or RADIUS users and any account in a group with SSL VPN access. Remove the ones you do not need and rotate the passwords of the ones you keep. The flaw only works with a valid alternate credential, so each one you delete removes a possible way in.

• Run the login correlation above back to at least the advisory date, and further back if your logs allow. Any VPN login with no identity provider sign-in behind it should be handled as a possible intrusion, not a logging glitch.

• Read the rest of the advisory. SNWLID-2026-0014 bundles seven CVEs. Two of them, in the web management interface, score 8.8, and others are crash bugs reachable before login in the SSL VPN and TACACS+ services. The same upgrade fixes all of them.

Detecting this kind of abuse depends on the identity provider and the firewall logs being compared side by side. That is the kind of correlation our threat hunting work is built around. Whoever does the comparing, the firewall logs show that a user logged in, and only the identity provider logs show whether that login went through MFA.