Skip to content
All posts

· by NetProtector Security Team

SonicWall: SSL VPN Flaw Bypasses MFA

Illustration: VPN tunnel through the firewall, with the login path bypassing the MFA check

Multi-factor authentication is considered the gold standard for securing VPN access. On SonicWall firewalls, however, it can currently be bypassed: through the vulnerability CVE-2026-19868, attackers log in to the SSL VPN without the SAML-enforced MFA taking effect. The US agency CISA added the flaw to its catalog of actively exploited vulnerabilities on November 6, 2026. There is no workaround – only the update.

What it is about

Many organizations connect SonicWall SSL VPN to their identity provider via SAML, for example Microsoft Entra ID or Okta. MFA is then enforced there as well. The problem: if an account also has a second login path – for example a local user account on the firewall or an LDAP connection – the gateway does not check the SAML policy. A login via this path gets through without SAML confirmation, and MFA is simply skipped.

The key facts according to SonicWall advisory SNWLID-2026-0014 of November 6, 2026:

  • Severity: CVSS 7.1 (SonicWall) or 7.5 (CISA). The ratings differ only in whether privileges are already required for the attack.
  • Affected: SonicOS Gen7 up to and including 7.3.3-7015 and Gen8 up to and including 8.2.2-8015 (including TZ, NSa, NSsp and NSv) – but only if SSL VPN is enabled and SAML is used for VPN login.
  • Fixed in: 7.3.4-7013 and 8.2.3-8015 respectively, and later.
  • Prerequisite for the attack: valid credentials for the alternative login path. So the attacker still needs a password – but no longer the MFA.
  • Consequence: a VPN session with the privileges of the compromised account, i.e. direct access to the internal network.

With the same update, SonicWall closes six further vulnerabilities in SonicOS, including two in the management interface (CVSS 8.8) and a buffer overflow in the SSL VPN service that can be triggered without authentication.

Why this is urgent

Stolen VPN passwords are not a bottleneck for attackers: they come from infostealer logs, previous data breaches, or are simply brute-forced. This is exactly what MFA is meant to protect against. Without it, a single valid password is enough to get into the network.

A case from this spring shows that this scenario is real. Starting in February 2026, the security company ReliaQuest observed attackers cracking SonicWall VPN accounts with automated brute-force attacks while exploiting an older MFA flaw (CVE-2024-12802) – on devices that had actually been patched. The reason: the firmware update alone did not remove the vulnerable LDAP configuration. MFA appeared to be active but did not stop the logins. The approach matched the ransomware group Akira, which had already specifically targeted SonicWall customers in 2025.

SonicWall has been in the spotlight in other ways in 2026 as well: between July and October alone, several zero-day vulnerabilities in the SMA1000 access gateways were actively exploited. VPN gateways are ideal targets for attackers – they are openly exposed to the internet and lead directly into the corporate network.

What you should do now

  1. Update. Install SonicOS 7.3.4-7013 or 8.2.3-8015 or later. Afterwards, check whether the configuration meets your expectations – the ReliaQuest case shows that an update alone is not always enough.
  2. Disable alternative login paths. Remove or deactivate VPN accounts that can also log in locally or via LDAP in addition to SAML. Keep an administrative access path open that does not run through the SSL VPN.
  3. Restrict VPN access wherever possible – for example to known IP ranges, countries or partner networks.
  4. Review logs. Search the SSL VPN login logs for successful logins without SAML on accounts that should only use SAML. Compare the source IP and time with the account's usual pattern, and watch for unusual activity in the internal network afterwards.
  5. If in doubt, treat the account as compromised: terminate sessions, reset credentials and check what was accessed from the VPN session.

What this means for firewall protection

CVE-2026-19868 is not an isolated incident but part of a pattern: the firewall is both a protective barrier and an attack surface. Its VPN portal must be reachable from the internet, and every vulnerability in it is a direct path into the network – often days or weeks before a patch is installed. On top of that, there are cases like CVE-2024-12802, in which the update alone does not protect either.

This is exactly where NetProtector comes in. The appliance sits inline in front of the firewall and filters malicious traffic before it even reaches the VPN portal:

  • Known attacker infrastructure is blocked. Brute-force attacks and mass scans against VPN portals come from sources that the NetProtector sensor network has already observed elsewhere. These sources are blocked before they try their first password on your systems.
  • Suspicious behavior is detected. High-frequency automated login attempts, scans for specific device types and firmware versions – such traffic anomalies are a typical warning sign before a vulnerability is exploited in a targeted manner.
  • Buying time until the patch. NetProtector does not replace the update. But it drastically reduces the number of attackers that reach the firewall at all – precisely during the period when a vulnerability is known but not yet closed.
Global early warning system
1Somewhere in the world, an attacker starts scouting for targets.
2Sensors register the suspicious behaviour and report it to the AI platform.
3The AI classifies the source as a threat and rolls out protection to every appliance.
4The attacker is blocked everywhere – before the attack can even begin.

How the early warning system works in detail and how NetProtector is deployed between router and firewall in two minutes is explained on the page How NetProtector works.

Our assessment

MFA remains a must – but it is only as strong as the device that enforces it. If a flaw in the firewall itself undermines MFA, even the best policy at the identity provider will not help. Securing VPN access therefore requires multiple layers: promptly installed updates, as few login paths as possible, monitoring of logins – and a protective layer in front of the firewall that intercepts attackers before they can even attempt to exploit a vulnerability.

Sources