SonicWall SSLVPN, falla CVE-2026-19868 aggira SAML e MFA: aggiornare SonicOS

Articolo aggiornato all’8 novembre 2026. La situazione è ancora in evoluzione: lo aggiornerò se SonicWall pubblica nuovi dettagli o nuove correzioni.

Avete configurato la VPN SSL del firewall SonicWall con login SAML, magari appoggiato a Entra ID con l’MFA obbligatoria, e vi sentite tranquilli? In questi giorni c’è un motivo per ricontrollare: SonicWall ha pubblicato l’avviso SNWLID-2026-0014 e una delle falle corrette, la CVE-2026-19868, permette di entrare nella VPN saltando proprio il passaggio SAML, e con lui l’MFA.

Il 6 novembre la CISA l’ha inserita nel catalogo delle vulnerabilità sfruttate attivamente (KEV). SonicWall parla di una segnalazione di “potenziale sfruttamento” senza fornire dettagli sugli attacchi, ma per me questo basta: un firewall perimetrale con una falla del genere si aggiorna subito, non alla prossima finestra di manutenzione.

Chi è coinvolto

Secondo l’avviso, il problema riguarda solo l’interfaccia o il servizio SSLVPN di SonicOS quando il login SSLVPN usa SAML. Le versioni interessate sono:

• Gen7 (TZ, NSa, NSsp e NSv): SonicOS 7.3.3-7015 e precedenti, corretta in 7.3.4-7013 o successive;
• Gen8 (TZ, NSa e NSv): SonicOS 8.2.2-8015 e precedenti, corretta in 8.2.3-8015 o successive.

Se la VPN SSL è spenta, oppure gli utenti si autenticano solo con utenti locali, LDAP o RADIUS senza SAML, questa specifica falla non vi tocca. Il firmware però va aggiornato lo stesso: lo stesso avviso corregge altre vulnerabilità, tra cui un heap overflow pre-autenticazione nella SSL-VPN (CVE-2026-82308) e due falle nell’interfaccia di gestione.

Perché succede

SonicOS può autenticare gli utenti SSLVPN con più metodi. Il difetto sta nel controllo di quale metodo debba essere obbligatorio: chi possiede credenziali valide per un metodo di autenticazione alternativo riesce a entrare senza passare dal flusso SAML. In pratica, se il vostro MFA è demandato all’identity provider via SAML, un attaccante con la password giusta di un altro tipo di account lo aggira del tutto.

SonicWall non ha indicato quali metodi alternativi rendano possibile l’attacco. È proprio per questo che, oltre all’aggiornamento, io farei pulizia degli account che possono accedere alla VPN: la falla richiede comunque una credenziale valida, e meno ce ne sono in giro meglio è.

Prima di iniziare

SonicWall dichiara che non esistono workaround: l’unica correzione è il firmware. Prima di aggiornare:

• esportate la configurazione corrente e salvatela fuori dal firewall;
• scaricate dal portale MySonicWall il firmware esatto per il vostro modello e leggete le release notes, in particolare la sezione sui percorsi di aggiornamento supportati;
• verificate che il contratto di supporto sia attivo, altrimenti il download non sarà disponibile;
• avvisate gli utenti: il riavvio fa cadere VPN e connettività per qualche minuto.

Attenzione: se avete una coppia in alta affidabilità, seguite la procedura HA indicata nelle release notes e non aggiornate le due unità a caso. E se il firewall è in un sito remoto, assicuratevi di avere qualcuno sul posto o un accesso fuori banda, nel caso qualcosa vada storto.

La procedura

1. Controllate la versione installata dalla dashboard di stato del firewall oppure dalla CLI in SSH con il comando qui sotto. Se siete su 7.3.3-7015 o precedenti (Gen7), oppure su 8.2.2-8015 o precedenti (Gen8), siete nel perimetro dell’avviso.

admin@FW01> show version

2. Verificate se la SSLVPN usa SAML. Se sì, la priorità è massima; se no, pianificate comunque l’aggiornamento entro pochi giorni per le altre falle.
3. Esportate la configurazione da Device → Settings → Firmware and Settings e conservatela insieme al firmware attuale, così potete tornare indietro.
4. Caricate il nuovo firmware (7.3.4-7013 o successivo per Gen7, 8.2.3-8015 o successivo per Gen8) e riavviate con la configurazione corrente.
5. A riavvio completato, ricontrollate la versione e fate una prova di connessione VPN con un utente SAML, verificando che l’identity provider chieda davvero il secondo fattore.
6. Rivedete chi può usare la SSLVPN: togliete dal gruppo SSLVPN Services (o dai gruppi che usate per la VPN) gli utenti locali e gli account di servizio che non devono collegarsi da remoto, e disattivate gli account locali di test rimasti dall’installazione.
7. Cambiate la password degli utenti locali che restano abilitati alla VPN e, se possibile, anche quella dell’amministratore del firewall.

Io preferisco che sulla VPN entrino soltanto utenti SAML con MFA, più al massimo un account locale di emergenza con password lunga, conservata in cassaforte digitale e controllata periodicamente. Ogni utente locale in più è una porta laterale, e questa falla lo dimostra bene.

Controllare se qualcuno è già entrato

Né SonicWall né la CISA hanno pubblicato indicatori di compromissione. Quello che potete fare è incrociare i log: cercate nei log del firewall gli accessi SSLVPN delle ultime settimane e confrontateli con i log di accesso dell’identity provider. Un login VPN riuscito che non ha un corrispondente accesso SAML con MFA, oppure un account pensato solo per SAML che risulta autenticato con un altro metodo, va trattato come sospetto.

Attenzione: se trovate qualcosa di strano, non limitatevi ad aggiornare. Disattivate l’account coinvolto, cambiate tutte le credenziali che passavano dal firewall e controllate i sistemi interni raggiungibili da quella sessione VPN.

Se il problema persiste

Se non potete aggiornare subito, ad esempio per un contratto scaduto o un modello senza firmware corretto, la scelta prudente è spegnere la SSLVPN finché non risolvete, oppure limitarne l’accesso a indirizzi IP noti. Non è un workaround ufficiale e non elimina la falla, ma riduce molto l’esposizione. Se il firewall non riceve più aggiornamenti, è il momento di metterne in conto la sostituzione. E se in azienda avete anche apparati di altri produttori, ricordo che pochi giorni fa è toccato ai Firebox WatchGuard e le 18 vulnerabilità di Fireware OS.

Vi è capitato di dover aggiornare di corsa un SonicWall in questi giorni, o avete trovato accessi VPN sospetti nei log? Raccontate nei commenti com’è andata: possono essere utili ad altri.