By Stet, wire reporter · TL;DR
Upgrade SonicOS to 7.3.4-7013 (Gen7) or 8.2.3-8015 (Gen8) (SonicWall). CVE-2026-19868 is in CISA's Known Exploited Vulnerabilities catalog with a due date of Nov 20 (KEV).
New today: SonicWall's advisory now has a workaround. Last week's coverage reported none. If SAML is in use and you can't upgrade, SonicWall says to "disable or delete any active LDAP, RADIUS, and TACACS+ authentication server configured on the firewall" (SonicWall).
Check first whether you're in scope. SonicWall says the flaw "ONLY impacts" SSL-VPN "if SAML is enabled for SSLVPN logins". Its own guide puts that setting at Network > SSL VPN > Server Settings, Authentication Type.
Claim Ledger
✅ Confirmed: SonicWall says the flaw "may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls" and "may also bypass SAML-enforced multi-factor authentication (MFA)". Affected: Gen7 "7.3.3-7015 and older versions", Gen8 "8.2.2-8015 and older versions", hardware and NSv. Fixed: "7.3.4-7013 and higher versions" and "8.2.3-8015 and higher versions" (SonicWall).
✅ Confirmed: SonicWall says its PSIRT "has investigated a report indicating potential exploitation of this vulnerability." That is SonicWall's wording: one report, potential exploitation (SonicWall).
✅ Confirmed: CISA added the CVE to KEV on Nov 6, due Nov 20. Its entry lists ransomware use as "Unknown" (KEV JSON).
✅ Confirmed: The advisory's revision 1.1, dated Nov 9, says "The Workaround section has been updated" for this CVE (SonicWall).
🗣️ Claimed: BleepingComputer headlined the flaw "exploited in attacks", stronger than SonicWall's "potential exploitation". It and SecurityWeek reported that no workarounds were available. Both ran before revision 1.1.
❓ Unknown: Who exploited it, against how many firewalls, and what it looks like in a log. The advisory gives no indicators. Also unknown: whether local user accounts count as an "alternate authentication method". The workaround names LDAP, RADIUS and TACACS+ only.
SonicWall changed its advisory today. Version 1.1 adds a workaround for CVE-2026-19868, the SSL-VPN flaw CISA put in KEV on Friday. BleepingComputer and SecurityWeek, both writing before the revision, reported there was none.
The workaround, in SonicWall's words: "If SAML authentication is in use and upgrading the firmware is not possible, disable or delete any active LDAP, RADIUS, and TACACS+ authentication server configured on the firewall." The advisory gives three menu paths, one per server type:
RADIUS: Device > Users > Settings > Authentication > Configure RADIUS > Settings > RADIUS Servers.
LDAP: Device > Users > Settings > Authentication > Configure LDAP > Settings > LDAP Servers.
TACACS+: Device > Users > Settings > Authentication > Configure TACACS+ > Settings > TACACS+ Servers.
Are you in scope?
SonicWall's advisory: "This vulnerability ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins."
Where that is set, per SonicWall's SonicOS 8 SAML Feature Guide: "Navigate to Network > SSL VPN > Server Settings." Then: "In the Authentication Type field, select SAML." SonicWall's knowledge-base article for SAML with Azure AD gives the same page: "Navigate to NETWORK | SSL VPN > Server Settings" and "Set Authentication Type as SAML". The SonicOS 7.3 SSL VPN guide puts the Authentication Type drop-down on that same page, default "Password". It doesn't list SAML among its options.
So: open that page. If Authentication Type reads SAML, you're in scope. If it reads Password or Certificate, SonicWall's note says this CVE doesn't apply to your SSL-VPN.
Why LDAP, RADIUS and TACACS+
The bug lets "a user with valid credentials for an alternate authentication method" get past SAML. Asked whether SSL-VPN can use local/LDAP accounts and SAML at the same time, SonicWall's SonicOS 8.1.0 FAQ answers no: it "can either be set to local/LDAP user accounts(Password) or SAML authentication or Certificates". Our read: on an unpatched firewall, the other methods still answer. That is why the workaround removes the servers behind them. SonicWall hasn't said that in those words.
Our read on the cost: those servers may carry other logins on the same box, such as admin access or user groups. Deleting them can break those. Upgrading doesn't. If the upgrade is possible, it's the shorter path.
The rest of the advisory
SNWLID-2026-0014 covers seven CVEs. CVE-2026-19868 is the only one SonicWall says it had a report of potential exploitation for. The advisory's top score, 8.8, belongs to two management-interface flaws, CVE-2026-107155 and CVE-2026-107154. Each "could potentially enable a remote unauthenticated attacker to perform unauthorized operations", with user interaction required. The advisory lists one set of fixed builds for all seven.
What we passed on
Refrigeration controllers: CISA, FBI, HHS, USDA and DOT warn that actors are targeting refrigeration and cold-chain monitoring systems, per The Hacker News. Find the ones reachable from the internet and remove remote access you don't need. We haven't read the joint advisory itself.
LNbits: the project told every operator to shut down their servers amid attacks; no fixed version as of 09:00 UTC, per The Hacker News. If you run it, shut it down until the fixes ship. We haven't read the project's own posts.
OpenSSH "SSHole", CVE-2026-123158: exploitation attempts have started, attributed to botnets and crypto miners, per SecurityWeek. Alpine and other musl systems with PAM disabled: patch and restart sshd.
Keplr wallets with Google or Apple sign-in: Web3Auth says a security issue in its own infrastructure affected certain wallets, and it moved at-risk funds into recovery wallets, per The Hacker News. Trust only official accounts; ignore "recovery" DMs.