SonicWall CVE-2026-19868: A Second Login Method Walks Past the MFA You Enforced on the VPN

The multi-factor prompt on a firewall's VPN portal is the one identity control most small businesses actually finish deploying. Mailbox MFA is usually partial. The admin console is usually exempt. The remote-access portal got the full treatment, because the firewall vendor turned it into a checkbox and somebody ticked it. CVE-2026-19868 reaches a session on the far side of that checkbox with a password and nothing else.

SonicWall published advisory SNWLID-2026-0014 on November 6. It covers seven CVEs in SonicOS and carries an advisory-level CVSS of 8.8. One entry in it is already drawing attack traffic: CVE-2026-19868, titled "SSLVPN Authentication Enforcement Vulnerability via Alternate Authentication Methods". SonicWall states the mechanism plainly. A user with valid credentials for an alternate authentication method may bypass SAML authentication controls, and successful exploitation may also bypass SAML-enforced MFA. The weakness class is CWE-308, use of single-factor authentication. SonicWall scores it 7.1 with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N and says PSIRT investigated a report indicating potential exploitation. The advisory's workaround field reads false. CISA added the CVE to the Known Exploited Vulnerabilities catalog on November 6 and set a federal remediation date of November 20 under BOD 26-04.

Here is the relevance verdict. The advisory scopes the flaw in one sentence: it only affects the SonicOS SSLVPN interface or service if SAML is enabled for SSL-VPN logins. If your remote users authenticate against local accounts, LDAP or RADIUS, and SAML was never switched on for that service, this CVE belongs to somebody else and you can skip the detection work below. Read the rest of the advisory anyway, because the other six CVEs carry no such condition. Two of them, CVE-2026-107154 and CVE-2026-107155, score 8.8 against the SonicOS management interface and reach a remote unauthenticated attacker. For an owner reading this: the door at risk is the one your staff use to work from home, and the account that opens it already reaches the file server.

A second authentication method is a second door

SAML on a SonicWall is an authentication method attached to a user domain, selected alongside whatever methods are already configured there. The multi-factor step does not live on the firewall. It lives at the identity provider, and the only route that visits the identity provider is the SAML route. Leave LDAP or a local account configured on the same domain and the appliance still answers a login that takes the other route. That route asks for one factor, because one factor is all it ever asked for.

CWE-308 is the category for precisely that gap: a system that accepts a single factor where policy says two. The policy was never wrong. The enforcement point had a second entrance.

Two public records disagree about what an attacker needs to start. SonicWall's vector says PR:L, low privileges, which means valid credentials for one of those alternate methods. The NVD record, published the same day and still marked "Undergoing Analysis", carries PR:N and a 7.5 base score. Plan around the vendor's reading and assume an attacker needs one username and password that the SAML policy does not govern. That is a low bar in 2026. Infostealer logs sell credentials in bulk, and VPN accounts are near the top of what buyers sort for. Both vectors agree on S:C, a scope change: the session this bug issues reaches past the firewall into the network behind it.

These appliances have history on that catalogue. CVE-2024-40766, a SonicOS access-control flaw from September 2024, is one of the KEV entries whose knownRansomwareCampaignUse field reads Known. Ransomware crews learned the SSL-VPN portal on this hardware two years ago and have not stopped checking it.

Read two values off every firewall before you decide anything

The affected list covers almost the entire current line. Gen7 hardware (TZ 270 through TZ 670, NSa 2700 through NSa 6700, NSsp 10700 through NSsp 15700) and Gen7 NSv virtual appliances are affected at 7.3.3-7015 and older. Gen8 hardware (TZ 80 through TZ 680, NSa 2800 through NSa 5800) and Gen8 NSv are affected at 8.2.2-8015 and older. The fixes are 7.3.4-7013 and higher, and 8.2.3-8015 and higher.

Two values decide your exposure: the firmware string, and whether SAML is enabled for SSL-VPN logins on the user domain the portal authenticates against. Take the firmware first, because a provider holding forty appliances cannot eyeball forty version strings and get it right.

#!/usr/bin/env bash
# sonicos_affected.sh - decide affected or fixed for SNWLID-2026-0014 from the
# firmware string on the device (Device > Settings, or "show version" in the CLI).
# One version per line:  ./sonicos_affected.sh < versions.txt

key() { printf '%03d%03d%03d%06d' "$1" "$2" "$3" "$4"; }

while read -r ver; do
  [ -z "$ver" ] && continue
  IFS='.-' read -r maj min pat build <<< "$ver"
  case "$maj" in
    7) fixed=$(key 7 3 4 7013) ;;
    8) fixed=$(key 8 2 3 8015) ;;
    *) echo "$ver  UNKNOWN - not Gen7/Gen8, read the advisory by hand"; continue ;;
  esac
  if [ "$(key "$maj" "$min" "$pat" "$build")" -ge "$fixed" ]; then
    echo "$ver  fixed"
  else
    echo "$ver  AFFECTED - upgrade to 7.3.4-7013+ (Gen7) or 8.2.3-8015+ (Gen8)"
  fi
done

The SAML question you can answer from outside, with no credentials and no session. Open the SSL-VPN portal in a private browser window. A portal with SAML enabled for SSL-VPN logins hands you a redirect to your identity provider's sign-in page. A portal without it renders the SonicOS form, with its own username, password and domain fields. One page load tells you which appliances are in scope, and it works just as well on the portals nobody remembers publishing.

What a large environment does differently, and the part of it that is free

I spend my days on the defensive side of a large network and my evenings on small-business engagements, and on this particular control the gap between them is not the budget. It is where the decision gets made. In a large environment the firewall does not judge whether a login is good. An identity provider judges, with a policy that evaluates the device as well as the human, and the VPN is one service provider among dozens that the same policy already governs. The appliance's own user database holds service accounts and nothing more. Both halves log to one place, so a VPN session with no matching assertion is a query somebody already wrote.

A forty-person company cannot buy that architecture this month. It can copy the part of it that would have blunted CVE-2026-19868, and the four moves below cost an evening.

Delete the methods the SSL-VPN domain does not use

This bug needs an alternate single-factor path to exist on the domain the portal authenticates against. Where SAML is the only method configured there, no second door is available to walk through. Most appliances still carry LDAP, RADIUS and local accounts because a predecessor configured them during a migration and nobody removed them afterwards.

Scope the portal to a group, not to everyone

SSL-VPN access granted to the default catch-all group makes every account the firewall can see a candidate credential. Granted to a named group of fifteen people, the set of usable credentials shrinks to fifteen.

Keep the management interface off the internet

The two 8.8 CVEs in the same advisory target the SonicOS management interface. An interface an attacker cannot reach is an interface an attacker cannot send a crafted request to. This is also the move that keeps the next management-plane CVE out of your week.

Send the authentication log somewhere the firewall does not control

SonicOS ships syslog to any destination you name. A free collector on an internal host gives you the one thing a patch cannot: evidence about what happened before you installed it.

The first two moves outlive this CVE. The patch closes one authentication bypass. Removing the unused method closes the class.

Find the sessions your identity provider never saw

The artifact this bug leaves behind is an absence. Somebody holds an SSL-VPN session, and the identity provider has no successful SAML assertion for that user in the minutes before it started. Build both sets and compare them. Where Entra ID is the SAML provider and sign-in logs reach a Log Analytics workspace, the first half is one query.

// Successful SAML sign-ins to the SonicWall SSL-VPN service principal.
// Keep this beside your SonicOS user-login events for the same window: an
// SSL-VPN logon with no row here in the preceding few minutes is the gap
// CVE-2026-19868 leaves behind.
let lookback = 21d;
SigninLogs
| where TimeGenerated > ago(lookback)
| where AppDisplayName has "SonicWall" or ResourceDisplayName has "SonicWall"
| where ResultType == 0
| extend Method = tostring(parse_json(AuthenticationDetails)[0].authenticationMethod)
| project TimeGenerated, UserPrincipalName, IPAddress, Method,
          ClientAppUsed, UserAgent
| order by TimeGenerated desc

The second half comes off the firewall. SonicOS records an SSL-VPN user login with the account name and the source address, so on a syslog collector this is a filter on the login category over the same range. Any logon whose user is missing from the KQL output within a few minutes earns a phone call to that person. A match on the user with a source address from another continent earns more than a phone call.

Then audit what the upgrade does not undo. Installing the fix closes the path and leaves in place everything a session already changed. Compare the running configuration against an export from before November 1 and look for four things: local user accounts you did not create, new membership in the group that grants SSL-VPN access, extra authentication methods enabled on the user domain, and a changed or deleted syslog destination. Check that last one first. An attacker who turns off your logging has told you what they expect you to look for.

Delete the authentication methods you are not using

The upgrade is this week's work: 7.3.4-7013 on Gen7, 8.2.3-8015 on Gen8, and CISA's November 20 date is a reasonable deadline for a private company to borrow. Do the firmware, then spend the hour that matters more. Open the user domain your SSL-VPN portal authenticates against and remove every method on it that no longer has a reason to be there. A control enforced on one path and absent on another gives you the reporting of a control and the protection of nothing.

If you own this decision but do not log into the firewall yourself, the question for your IT provider is short: which login methods can reach our VPN, and which of them require the second factor? Two answers that do not match is the finding. We run that review as part of our identity work, and on a single-firewall network it takes an afternoon.