SonicWall has confirmed a new vulnerability, CVE-2026-19868, that lets an attacker who already holds valid credentials for one login method slip past SAML single sign-on entirely — including the multi-factor authentication most businesses expect SAML to enforce. The flaw sits in SonicOS, the operating system running SonicWall's Gen7 and Gen8 firewalls (versions 7.3.3-7015 and 8.2.2-8015 and earlier), and only affects SSL-VPN connections configured to authenticate through a SAML identity provider. This is a different product and a different bug from the SMA1000 remote-access appliance flaws SonicWall patched earlier this year — the common thread is the vendor, not the vulnerability.
The mechanism is subtle but serious: if a SonicOS firewall is set up to allow more than one way to log in — for example, SAML plus a local account kept as a fallback — an attacker who compromises or already holds credentials for that secondary method can use them to bypass the SAML path altogether, sidestepping the conditional-access policies and MFA enforcement the business thinks is protecting every login. SonicWall rates the flaw CVSS 7.1 and has stated it investigated a report indicating the vulnerability was exploited in an attack. CISA added the bug to its Known Exploited Vulnerabilities catalog on 6 November, confirming it is already being used in the wild, and has given U.S. federal agencies until 20 November to secure affected systems — a deadline worth treating as a guide even if your organisation isn't a federal agency.
What this means for your business
If your organisation, or the IT provider managing your network, runs a SonicWall firewall with SSL-VPN remote access, check today whether SAML authentication is in use and whether any alternate login method is still enabled alongside it. SonicWall has released fixed firmware — 7.3.4-7013 for Gen7 and 8.2.3-8015 for Gen8 — and has stated plainly that no workaround exists, so updating is the only real fix. Given active exploitation is already confirmed, this is worth treating as urgent rather than scheduling it for the next routine maintenance window.
Beyond patching, this is a good prompt to ask a broader question: does your remote-access setup have a login method sitting unused, kept around for convenience or as a fallback? This flaw is a reminder that every additional way into a system is also an additional way around the protections built into the main one. If nobody on your team can explain why a secondary authentication method is still enabled, that is usually a sign it should be switched off.