CISA Lists an Exploited SonicWall SSL-VPN Flaw That Gets Past SAML and Its MFA: CVE-2026-19868. Patch Gen7 and Gen8 by November 20, and Check Which Accounts Can Still Sign In Another Way.
If you run a SonicWall firewall with SSL-VPN sign-in through SAML, update SonicOS today and then look at which accounts can sign in some other way. CISA added CVE-2026-19868 to its Known Exploited Vulnerabilities catalog on November 6, 2026. The flaw lets someone who holds valid credentials for a different sign-in method get around the SAML controls, and that can include the multi-factor check the SAML provider enforces.
What CISA says
The catalog entry names it a SonicWall SonicOS SSLVPN use of single-factor authentication vulnerability, filed under CWE-308. The description reads that a user with valid credentials for an alternate authentication method may bypass SAML authentication controls, and that successful exploitation may also bypass SAML-enforced MFA. Federal agencies have until November 20, 2026 to apply the vendor's fix under CISA's BOD 26-04. The catalog marks known ransomware use as unknown. SonicWall's advisory is SNWLID-2026-0014.
What the flaw is, in plain terms
This is not a way in with no credentials. Going only by the one-sentence description, it looks like a way to skip the second factor and the identity provider's rules. If an account has credentials that work on a path other than SAML, for example a local SonicWall account, that path may reach the SSL-VPN without the MFA your SAML provider enforces ever being asked. That is our reading of a short description, not a mechanism SonicWall has published. The danger is the gap between the sign-in method you meant to require and the ones the firewall still accepts.
Who is exposed
Secondary reports say it affects SSL-VPN configured for SAML on SonicOS Gen7 versions 7.3.3-7015 and earlier, and Gen8 versions 8.2.2-8015 and earlier. They report fixed builds 7.3.4-7013 and 8.2.3-8015 and say SonicWall offers no workaround. Reports of the score disagree: 7.1 is the most common figure, one outlet gives 7.5, and one aggregator shows 0, which looks like a placeholder. We are not quoting a score.
What to do now
- Update to the fixed build for your generation, then confirm the version on the device.
- List every account that can reach the SSL-VPN without going through SAML. Local accounts and any other configured sign-in method are the ones this flaw relies on.
- Review SSL-VPN sign-in logs from those accounts since the first date you can see, and flag any that signed in without a SAML step.
- Follow CISA's forensics triage guidance if you cannot rule a sign-in out. The catalog entry points to it.
- These steps are our reading of the flaw, not text from the advisory. Where the advisory says something different, follow the advisory.
Indicators
None were published in the sources we read, so there is nothing to add to the feed. The CVE syncs into our KEV index on its own and we do not hand-ingest it.
Limits
We read the CISA catalog entry through our own KEV index and search coverage from several outlets. We could not open SonicWall's advisory page or the NVD record: both load their content with scripts and returned only a page title. So the affected and fixed versions and the no-workaround statement are as reported by others, and we did not test the flaw or check any device. CISA listing it means it has evidence of exploitation, and SonicWall is reported to say the same, but we have seen none of it ourselves and have no edge or honeypot sighting.
Five percent of this is wrong somewhere. It always is. The advisory will correct a version number or a detail about which configurations are exposed.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.