SonicWall's SSL VPN bug lets a valid password skip SAML and your MFA

SonicWall firewalls that send VPN logins through SAMLdefinitionThe standard that lets the firewall hand a login to an identity provider like Entra ID. The provider checks the user, usually with MFA, then vouches for them. can be talked past. Someone with a working password for another sign-in method can skip the SAML step, and the MFA your identity provider enforces never gets asked. SonicWall says it has a report of exploitation, CISA added the flaw to its exploited list on November 6, and the fixed builds are out. Upgrade before November 20.

A VPN login is a way into your network. If the MFA in front of it can be skipped, a password stolen in a phishing email or reused from an old breach is enough to get inside. From there, whoever holds the session can reach whatever that user's VPN access allows.

How likely is it? SonicWall's PSIRT says it investigated a report of potential exploitation and urges customers to upgrade as soon as possible. Canada's Cyber Centre puts it more bluntly: SonicWall indicates the flaw is being exploited. CISA's catalog marks ransomware use as unknown for now.

The two severity scores tell you something too. SonicWall rates it 7.1 and assumes the attacker already has low-level privileges. CISA's analysts scored it 7.5 with no privileges required. Our reading is that, from the firewall's side, a valid password for another method is all it takes. Either way, it needs a working credential. That's why it sits at high rather than critical, and why it's still dangerous: working credentials are exactly what attackers collect.

SonicWall's SSL VPN has a history here. CISA's list already holds earlier SonicOS flaws, among them CVE-2024-40766 and the SSL VPN authentication bypass CVE-2024-53704, both now marked as used in ransomware campaigns. If your firewall was slow to get those fixes, treat this one as a test of whether that's changed.

CISA files it as CWE-308, use of single-factor authentication. SonicWall hasn't said which alternate methods count. The firewall can still check local users and directory accounts itself, so look at those first. SonicWall's SAML guide names SSLVPN ServicesdefinitionThe default SSL VPN group on a SonicWall. SonicWall's SAML guide says users must be in it to connect. Other groups can be given VPN access to specific networks. as the default VPN group. Its members are who can connect, so start there, then check what each group's VPN access lets it reach.

The table has a trap for virtual firewalls. The advisory names 7.3.4-7013 as the first fixed Gen7 build, but SonicWall's release notes for 7.3.4-7013 say the NSvdefinitionSonicWall's virtual firewall, run on VMware, KVM, Hyper-V or in AWS and Azure. It sometimes gets builds later than the hardware. version wasn't released at that point. NSv 270, 470 and 870 get the fix in 7.3.4-7015. If someone ticked off your virtual firewalls because "7.3.4-7013 is out", check them again.

Watch for a second mismatch if you work from a feed. Canada's Cyber Centre bulletin describes the affected range as "prior to 8.2.2-8015" for Gen8, while SonicWall's advisory and the CVE record say 8.2.2-8015 itself is affected and the fix is 8.2.3-8015. Go by SonicWall's page. A firewall on 8.2.2-8015 still needs the upgrade.

The most useful check takes a few minutes and needs no special tools. When SAML works as designed, every VPN session starts with a sign-in at your identity provider. A session that shows up on the firewall with no matching sign-in at the provider either came in another way or points to a gap in your logs. Both are worth knowing about.

SonicWall's own guide shows where to find the firewall side. Under Device, Log, Settings, open the Users category and Group Authentication Access, then set event 1080 to display in Log Monitor. Event 263 records user logouts. Do it now, even before you upgrade, so the next login gets logged.

The upgrade closes this hole. The weakness underneath is older: firewalls collect side doors over the years. A local admin account from the install, a test user nobody removed, an LDAP fallback someone added during an outage. Each one is a login that doesn't go through your identity provider. Close those and the next authentication bug has less to work with.

We made all three up. None is a real incident or a Cohash client, though the versions and behaviour match what SonicWall, CISA and Canada's Cyber Centre have published.

We don't sell or run SonicWall, and the firewall upgrade stays with whoever manages it. Our work starts at the identity provider. Our identity and access management team tightens the VPN's SAML app in Microsoft Entra ID and tracks down accounts that still log in around it. When the cleanup needs more hands, our Entra ID engineers can join for a few weeks. If you're not sure where your side doors are, the free assessment is the place to start.