SonicWall SonicOS: Attackers Bypass MFA in SSL-VPN — Now in CISA's Catalog

SonicWall released an emergency update for its SonicOS firewalls, closing a multi-factor authentication (MFA) bypass vulnerability in the SSL-VPN service. The vulnerability received the identifier CVE-2026-19868 and, per the US Cybersecurity and Infrastructure Security Agency (CISA), is already being actively exploited.

The problem: an attacker who holds valid credentials for one of the alternative login methods (for example, a local account, LDAP, or RADIUS) can bypass SAML authentication and, consequently, the MFA enforced by the SAML provider. Simply put: if SAML is enabled for SSL-VPN login on the firewall but another login method remains, the attacker can "slip" through it, completely bypassing the extra protection factor.

CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on November 6, 2026, with a deadline of November 20, 2026 for US federal civilian agencies. Such a deadline means one thing: the vulnerability is confirmed in real attacks, and there's no time to delay.

Technical breakdown: how the bypass works

SonicWall's official description reads: "an authentication bypass vulnerability in the SonicOS SSLVPN service may allow a user with valid credentials for an alternative authentication method to bypass SAML authentication controls. Successful exploitation may also bypass multi-factor authentication (MFA) enforced by SAML."

Key technical characteristics:

• CVSS score: 7.1 (v3.1 per SonicWall; some sources cite 7.5), High.
• Attack vector: network, but with high complexity (AC:H) — exploitation requires specific conditions.
• Precondition: the attacker must have valid credentials for an alternative login method (local account, LDAP, or RADIUS).
• Trigger condition: the vulnerability affects only configurations where SAML is enabled for SSL-VPN login.
• Consequence: unauthorized remote access to the internal network, bypassing the second factor.

In other words, the vulnerability itself doesn't allow login without a password — it lets someone who already holds one set of valid credentials shed the additional SAML/MFA protection layer. This is a classic "authentication-control bypass," not a full authentication bypass.

A public proof-of-concept script has already appeared online demonstrating the approach: it takes the target device address, login/password, and login method (local/LDAP/RADIUS) and obtains an authenticated SSL-VPN session bypassing SAML. The availability of such PoCs lowers the entry barrier for less experienced attackers.

Quick primer: why MFA and SAML aren't the same thing

To grasp the issue, it's worth distinguishing two often-confused concepts.

MFA (multi-factor authentication) is a general principle: to log in, a user must prove identity with two or more factors (something they know — a password; something they have — a phone with an authenticator app; something they are — a fingerprint). The idea is that a stolen password alone isn't enough.

SAML (Security Assertion Markup Language) is a protocol that lets you delegate authentication to an external identity provider (e.g., Microsoft Entra ID, Okta, or Google Workspace). When a user connects to the VPN, the firewall redirects them to the identity provider, which verifies identity (and may require MFA) and issues an "assertion" that the user is who they claim to be.

The CVE-2026-19868 problem arises at the junction of these two mechanisms. If SAML is enabled for SSL-VPN on the SonicWall, but another "bypass" login method (local account, LDAP, RADIUS) also exists, an attacker with valid credentials for that alternative method can log in past SAML — and therefore past the MFA the SAML provider enforces. They have the password, but no longer need to present the second factor.

That's exactly why the vulnerability is classified as an "alternative-method authentication bypass" rather than "password guessing": without valid credentials the hole doesn't work, but with them it fully removes the extra protection layer.

Why this is dangerous right now

Several circumstances make this situation especially alarming:

1. Confirmed exploitation. Inclusion in CISA's KEV catalog is not a theoretical threat but official confirmation that the vulnerability is used in the wild. SonicWall also stated it had "investigated reports of potential exploitation of this vulnerability."
2. MFA as the last line. For many organizations the VPN gateway is the "door" into the internal network, and MFA is the main defense of that door against stolen credentials. Bypassing MFA means even passwords compromised via phishing or leaks give the attacker full access.
3. SonicWall is a widespread platform. SonicWall firewalls are used en masse in small and medium business, including in Ukraine. Such a broad install base makes the vulnerability an attractive target.
4. No workaround. SonicWall explicitly states there is no mitigation — the only way to protect is a firmware update. Until then, vulnerable systems remain open.
5. History of attacks on SonicWall in 2026. Throughout the year, SonicWall devices were repeatedly targeted by zero-day campaigns, showing persistent attacker focus on the platform.

Perimeter VPN devices — a favorite target

This vulnerability doesn't exist in a vacuum. Throughout 2025–2026, firewalls and VPN gateways became one of the world's top cyberattack targets. The reason is simple: these devices sit on the perimeter, have publicly reachable interfaces, often go unpatched for months, and give the attacker ready access to the internal network.

CISA has repeatedly warned that perimeter network devices (VPN gateways, firewalls, routers) are among the most exploited targets. The attackers' logic is clear: why break individual workstations when you can gain access through one entry point that by definition lets "insiders" through?

The MFA bypass is especially painful here. When an organization deploys MFA, it usually believes it has solved the stolen-password problem. But a configuration flaw — where an unprotected alternative method remains alongside the protected SAML login — nullifies all that work. This is a lesson for everyone: authentication security is defined by the weakest link, not the strongest.

For Ukrainian companies this carries extra weight. Under constant pressure on infrastructure, unpatched perimeter devices are a direct invitation to attackers. Even if your organization isn't a direct state-actor target, automated scanners and opportunistic groups actively hunt vulnerable VPN gateways.

Other vulnerabilities in the same update

The SonicWall update fixes not one but seven vulnerabilities in SonicOS. Worth highlighting:

• CVE-2026-107155 (CVSS 8.8) — an overly permissive cross-domain policy in the SonicOS management interface, which under certain conditions lets a remote unauthenticated attacker perform unauthorized operations.
• CVE-2026-107154 (CVSS 8.8) — a session-validation flaw in the SonicOS management interface, also with potential for unauthorized operations by an unauthenticated attacker.
• CVE-2026-82308 (CVSS 7.5) — a heap-based buffer overflow in the pre-authentication SSL-VPN service, which can lead to denial of service (DoS).
• Additional flaws — a pre-authentication buffer overflow in the TACACS+ service (DoS) and weak password hashing in virtual appliances.

Pay special attention to the two 8.8-rated management-interface flaws — even if you don't use SSL-VPN with SAML, these can affect the device.

Which versions are vulnerable and who's at risk

The following SonicOS versions are vulnerable:

At risk are organizations that:

• use SonicWall firewalls with SonicOS Gen7 or Gen8;
• enabled SAML for SSL-VPN login;
• simultaneously have another login method (local account, LDAP, or RADIUS), a typical configuration for backup access.

Tellingly, even if MFA looks "enabled," a configuration with multiple login methods effectively nullifies it for an attacker holding valid credentials for the alternative method.

How to protect yourself: a step-by-step plan

1. Determine the firmware version. Log into the SonicWall management interface and check the SonicOS version. Gen7 ≤ 7.3.3-7015 or Gen8 ≤ 8.2.2-8015 means the device is vulnerable.
2. Update immediately. Install SonicOS 7.3.4-7013 (Gen7) or 8.2.3-8015 (Gen8). There's no workaround — updating is the only way to close it. For US federal agencies the deadline is November 20, 2026, but no business should delay in practice.
3. Review SSL-VPN login methods. If SAML is enabled, ensure alternative login methods (local accounts, LDAP, RADIUS) are limited to what's truly needed and don't open a bypass path. The "minimum login methods" principle shrinks the attack surface.
4. Check logs. Analyze SSL-VPN logs for the last few weeks for suspicious logins: unusual IPs, authentication at atypical times, logins via a method different from the user's norm. SonicWall provides no dedicated compromise-check procedure for this flaw, so vigilance about anomalies is especially important.
5. Apply zero trust. An MFA bypass on the perimeter reminds us: don't rely on the VPN gateway alone as the trust boundary. Segment the network, limit lateral movement, and require separate authentication to critical systems.
6. Check whether your credentials leaked. Since the attack relies on valid credentials, verify employee accounts aren't compromised — use the free breach check on cyberpeople.tech.

Conclusion

CVE-2026-19868 is another reminder that multi-factor authentication only protects when it can't be bypassed via configuration. The SonicWall SonicOS vulnerability is confirmed exploited, has no workaround, and public PoCs are already available — this makes a firmware update a matter of days, not weeks.

For Ukrainian organizations using SonicWall as a VPN gateway, the main recommendation is simple: check the SonicOS version and update to 7.3.4-7013 or 8.2.3-8015 immediately, review SSL-VPN login methods, and make sure no alternative method opens an attacker a path around MFA. Combining timely patching with network segmentation and breach-checking credentials is the minimum that lowers risk to an acceptable level.

More on building defense against such threats in our cybersecurity learning material.