SonicWall shipped SonicOS updates on 6 November 2026 for seven vulnerabilities, and one of them is already being used in an attack. CVE-2026-19868 lets a user who holds valid credentials for a different authentication method get past SAML controls on the SSL-VPN service, which in practice can mean getting past the MFA that SAML was there to enforce.
What happened
The flaw is an authentication enforcement problem, rated CVSS 7.1 by SonicWall and 7.5 by CISA, with the vendor's vector showing network reach, high attack complexity and no privileges required. It only affects the SSLVPN interface or service when SAML is enabled for SSL-VPN logins. SonicWall's PSIRT said it investigated a report indicating exploitation and urged customers to upgrade immediately. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 6 November with a 20 November federal deadline.
The same advisory covers six other flaws: two management interface issues rated 8.8 that allow unauthenticated operations under specific conditions, two pre-authentication buffer overflows in the SSL-VPN and TACACS+ services, and weak password hashing on virtual appliances. There is no workaround. The only fix is the firmware.
Who is affected
- Gen7 firewalls on 7.3.3-7015 and older, including the TZ 270 through TZ 670, NSa 2700 through NSa 6700 and the NSsp 10700 to 15700 line
- Gen7 NSv virtual firewalls on 7.3.3-7015 and older, on ESX, KVM, Hyper-V, AWS or Azure
- Gen8 firewalls from the TZ 80 to TZ 680 and NSa 2800 to NSa 5800 on 8.2.2-8015 and older, plus the Gen8 NSv XS to NSv L appliances
- Only sites that have SAML enabled for SSL-VPN authentication, but that is the normal design for any organisation enforcing MFA on remote access
What to do now
Upgrade to Gen7 7.3.4-7013 or Gen8 8.2.3-8015 now, then read the access logs for SSL-VPN logins that did not complete SAML.
- Check whether SAML is enabled for SSL-VPN. If it is, treat this as an urgent upgrade rather than a scheduled one.
- After upgrading, look for SSL-VPN sessions authenticated by a local or RADIUS account instead of the SAML identity provider, and for accounts created or changed around those sessions.
- Rotate credentials for any local account that can still reach SSL-VPN, since a bypass means the second factor never had a chance to reject the login.
- Apply the same build to every firewall in the estate, including the standby unit in an HA pair, or the pair will not fail over cleanly.
What this means for South African businesses
Most SonicWall deployments at South African SMEs are exactly the shape this flaw targets: a TZ or NSa firewall terminating remote access, with SAML pointed at Microsoft 365 so that MFA is enforced. The abuse path needs a working password, which is what makes it dangerous rather than theoretical, because password reuse and leaked credentials are the common way a perimetre is lost here. My read is that an SME with SSL-VPN open to the internet and SAML enabled should assume this is being probed, and should not wait for a maintenance window.
Source: SonicWall PSIRT advisory SNWLID-2026-0014.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.