SonicWall, la falla che aggira l’MFA con credenziali valide

C’è una frase che negli ultimi tre anni è stata pronunciata in centinaia di consigli di amministrazione italiani, quasi sempre con lo stesso tono rassicurante: “sulla VPN abbiamo attivato l’autenticazione a due fattori“. Il CdA annuisce, il punto viene verbalizzato, il rischio “accesso remoto” scivola dal rosso all’arancione nel registro, e si passa all’ordine del giorno successivo.

Nessuno, in quella stanza, ha chiesto che cosa significhi esattamente “attivato”, né per quali porte d’ingresso, né se l’apparato che fa da portinaio sappia davvero dire di no a chi arriva da un’altra porta.

Il 6 novembre 2026 SonicWall ha pubblicato un avviso che risponde a quella domanda mai posta, e la risposta non è gentile. La vulnerabilità CVE-2026-19868, nel servizio SSL-VPN di SonicOS, permette a chi possiede credenziali valide per un metodo di autenticazione alternativo di saltare a piè pari i controlli SAML, inclusa l’autenticazione multifattore che proprio su SAML era stata appoggiata.

Tradotto per il CdA: l’MFA c’era, era configurata, era pure verbalizzata. Solo che il firewall, in certe condizioni, accettava anche chi non ci passava attraverso.

Non è una falla che apre la porta a chiunque. Serve una password giusta, e questo è il dettaglio che il reparto IT userà per difendersi e che il CdA dovrebbe invece usare per preoccuparsi. Perché le password giuste, oggi, non si indovinano: si comprano.

Gli infostealer le raccolgono dai portatili dei dipendenti, i broker di accesso iniziale le impacchettano per settore e per paese, e gli operatori ransomware le acquistano come si acquista un abbonamento. L’MFA era nata esattamente per rendere inutile quel mercato. Questa falla lo rimette in piedi.

SonicWall, la falla che aggira l’MFA: cosa è successo

L’avviso SonicWall porta la sigla SNWLID-2026-0014 e corregge sette vulnerabilità di SonicOS in un colpo solo, ma una sola delle sette ha avuto l’onore della cronaca. CVE-2026-19868 è classificata come CWE-308, “uso di autenticazione a singolo fattore”, con un punteggio CVSS 3.1 di 7,1 assegnato dal vendor e ripreso dall’ACN nel proprio avviso; l’enrichment CISA-ADP sul record NVD riporta invece 7,5 con vettore AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N, cioè nessun privilegio richiesto e impatto che esce dal perimetro del solo firewall.

Il PSIRT di SonicWall dichiara di aver indagato una segnalazione che indicava un possibile sfruttamento, formula prudente che in questo settore significa quasi sempre “qualcuno l’ha già usata”. Lo stesso 6 novembre CISA ha inserito la CVE nel catalogo KEV sulla base di evidenze di sfruttamento attivo, e ha dato alle agenzie federali americane tempo fino al 20 novembre per sistemare gli apparati. Quattordici giorni, che sono la misura dell’urgenza percepita da chi ha visto i dati.

Il perimetro è preciso e vale la pena rispettarlo, perché l’allarmismo è il cugino sciocco della sicurezza. La falla colpisce il servizio SSL-VPN di SonicOS solo quando l’autenticazione SAML è abilitata per i login VPN. Le piattaforme coinvolte sono i firewall di settima e ottava generazione: il record CVE indica come affette le versioni Gen7 fino a 7.3.3-7015 e Gen8 fino a 8.2.2-8015; le versioni corrette sono 7.3.4-7013 e 8.2.3-8015.

SonicWall non indica alcuna soluzione temporanea: o si aggiorna, o si resta esposti. Il ricercatore accreditato nell’avviso è Ryan Harris di The Electronic Office, il che ricorda che questa classe di falle emerge quasi sempre da chi configura gli apparati per mestiere e nota che qualcosa, nei log, non torna.

Un dettaglio di contesto che chi gestisce SonicWall conosce fin troppo bene: nel 2026 la linea SMA 1000 ha collezionato una sequenza di avvisi con zero-day sfruttati e punteggi fino a 10 su 10, e nei commenti di settore si è iniziato a parlare di un pattern più che di incidenti isolati.

La CVE di oggi riguarda i firewall e non gli SMA, ma il messaggio per chi compra è lo stesso: gli apparati di accesso remoto sono diventati il bersaglio preferito perché stanno sul confine, si aggiornano poco e, quando cedono, consegnano direttamente la rete interna.

In Italia, dove SonicWall è una presenza familiare in studi professionali, PMI manifatturiere e piccole strutture sanitarie, il bacino potenziale non è trascurabile.

Come funziona il bypass, senza bisogno di un dottorato

Un firewall SonicOS può autenticare gli utenti della SSL-VPN in più modi contemporaneamente: un database locale di utenti, un server RADIUS o LDAP aziendale, e SAML, che delega il login a un Identity Provider esterno come Entra ID, Okta o Google Workspace.

L’MFA, nella stragrande maggioranza delle installazioni moderne, vive dentro l’Identity Provider: è lui che chiede il secondo fattore, è lui che applica le policy di accesso condizionale, è lui che decide se quel dispositivo da quella geografia a quell’ora può entrare. Il firewall si limita a fidarsi dell’asserzione SAML che torna indietro. Finché tutto il traffico passa da quella porta, il modello regge.

Il problema descritto da CVE-2026-19868 è un difetto di enforcement: il gateway, pur configurato per richiedere SAML sul portale SSL-VPN, non impediva a un account con credenziali valide per uno dei metodi alternativi di aprire una sessione VPN attraverso quel metodo, saltando interamente il giro dall’Identity Provider.

Niente redirect, niente richiesta del secondo fattore, niente policy condizionale, perché l’IdP non viene mai interpellato. La sessione risulta regolarmente aperta, l’utente è “autenticato”, e il firewall non ha mentito: ha solo accettato una strada che il manuale non diceva di chiudere e che l’amministratore pensava fosse murata.

Qui sta l’inganno concettuale che vale per molti apparati, non solo per SonicWall. Attivare un metodo di autenticazione forte non disattiva automaticamente quelli deboli che gli stanno accanto. Il tipico scenario italiano è una migrazione a metà: si passa a SAML con MFA per i dipendenti, ma restano in piedi gli account locali creati dal fornitore IT per “l’emergenza”, l’utenza RADIUS della stampante o del sistema di backup, il gruppo LDAP legacy di una controllata acquisita.

Ciascuno di questi è, per il firewall vulnerabile, una porta di servizio con una serratura a un solo giro. E le credenziali di quelle porte sono spesso le più vecchie, le meno ruotate, le più facili da trovare in un dump di infostealer di tre anni fa.

In un engagement reale la catena si vede nitida: l’attaccante compra o recupera una coppia utente/password aziendale, prova il portale SSL-VPN, scopre che accetta anche il login “classico” nonostante il bottone SAML in bella vista, entra, e da lì il problema smette di essere una vulnerabilità del firewall e diventa un problema di segmentazione interna.

Il ransomware arriva giorni dopo, ma il momento in cui la partita è stata persa è quel singolo login senza secondo fattore che nessuno ha visto, perché i log dell’IdP non mostrano niente di anomalo. Non c’è niente da mostrare: l’IdP non è mai stato chiamato.

Pillole per chi deve capire in fretta

SAML. Security Assertion Markup Language è il protocollo con cui un servizio (qui la VPN) delega il login a un Identity Provider fidato. L’utente viene rimandato all’IdP, si autentica lì con tutti i fattori del caso, e torna al servizio con un’asserzione firmata che dice “questa persona è chi dice di essere”. Il punto debole non è mai la firma: è cosa succede quando il servizio accetta anche altre strade.

CWE-308, uso di autenticazione a singolo fattore. Non è un bug di memoria né un errore di codice in senso stretto; è una debolezza di progettazione per cui un percorso di accesso richiede meno fattori di quanto la policy dichiari. SonicWall ha scelto questa classificazione per dire, con onestà, che il firewall faceva esattamente ciò che era programmato a fare, e che il programma era sbagliato.

Catalogo KEV. Known Exploited Vulnerabilities, gestito da CISA: entra solo ciò per cui esiste evidenza di sfruttamento reale. Per le agenzie federali americane la scadenza di rimedio è vincolante; per tutti gli altri è il miglior indicatore gratuito di cosa patchare oggi e non al prossimo change window. Quando una CVE entra in KEV il giorno stesso dell’avviso, il margine tra “possibile” e “accertato” si è già consumato prima che il pubblico ne sapesse qualcosa.

CVSS 7,1 e perché il numero inganna. Il punteggio è “alto” e non “critico” perché la metrica richiede privilegi, cioè una password valida. Ma CVSS misura la difficoltà tecnica, non la facilità economica. Con decine di milioni di credenziali aziendali in circolazione sui mercati criminali, il prerequisito “serve una password” costa qualche decina di dollari. Un 7,1 con prerequisito a basso costo è operativamente più pericoloso di molti 9 che richiedono condizioni di laboratorio.

L’MFA non è un oggetto, è un percorso. Dire “abbiamo l’MFA” è come dire “abbiamo la porta blindata” in una casa con quattro ingressi. La domanda corretta è: quali percorsi di autenticazione accetta ciascun servizio esposto, e su ciascuno di essi è imposto un secondo fattore? Un esempio concreto: in molte PMI l’account “admin-locale” creato dal system integrator al momento dell’installazione non è mai stato disabilitato, non è mai passato a SAML e ha ancora la password del 2021. Quella non è un’eccezione all’MFA: è l’assenza di MFA, con una targhetta rassicurante sopra.

Credenziali valide, il prerequisito che non rassicura. Gli infostealer (RedLine, Lumma, Vidar e i loro successori) infettano un PC personale su cui il dipendente ha salvato anche la password aziendale nel browser, e la vendono in lotti indicizzati per dominio. Un attaccante che cerca “@nomeazienda.it” nei log di uno stealer trova spesso proprio la coppia che serve per la VPN. Il secondo fattore era l’unica cosa che rendeva quel lotto senza valore. Senza enforcement, torna a valere il prezzo pieno.

Cosa fare questa settimana, non al prossimo budget

La prima mossa è banale e per questo spesso rinviata: aggiornare. SonicOS 7.3.4-7013 su Gen7, 8.2.3-8015 su Gen8, nessuna alternativa, nessun workaround. Chi ha un contratto di supporto scaduto scoprirà adesso quanto costa non averlo rinnovato; chi ha il firewall gestito da un fornitore esterno scoprirà se il fornitore legge gli avvisi PSIRT o aspetta che glielo chieda il cliente.

Entrambe le scoperte vanno annotate, perché sono informazioni sulla filiera e non solo sul firmware.

La seconda mossa è quella che il patch da solo non fa: l’inventario dei metodi di autenticazione. Sul portale SSL-VPN vanno elencati tutti i metodi attivi, uno per uno, e per ciascuno va risposto a una domanda sola: chi può entrare da qui e con quanti fattori?

Gli account locali di emergenza vanno disabilitati o messi dietro un secondo fattore nativo; le utenze di servizio RADIUS vanno ristrette agli indirizzi sorgente che le usano davvero; i gruppi LDAP ereditati vanno chiusi o migrati. Dopo il patch il firewall farà rispettare SAML; ma un account locale con password debole resta un account locale con password debole, e il prossimo bug lo troverà ancora lì.

La terza mossa è la caccia retrospettiva, perché la CVE è in KEV e quindi il “se” è già stato deciso da qualcun altro. Va detto subito che né l’avviso SonicWall né la nota ACN forniscono indicatori di compromissione: quanto segue viene da analisi di terze parti e va trattato come traccia di caccia, non come lista ufficiale.

SonicOS registra i login SSL-VPN con un evento dedicato (ID 1080) che riporta il metodo di autenticazione usato: ogni sessione aperta con un metodo diverso da SAML su un portale che SAML doveva imporre è un indizio da spiegare. Il controllo incrociato decisivo è però con l’Identity Provider: si prendono le sessioni VPN degli ultimi mesi e si cerca, per ciascuna, il corrispondente accesso sui log di Entra ID o Okta. Una sessione VPN senza un sign-in gemello sull’IdP non è un’anomalia statistica, è una porta aperta da qualcuno che l’IdP non ha mai visto. Un esempio: utente “m.rossi” con sessione VPN alle 03:12 di un sabato da un IP residenziale estero, nessun evento di autenticazione su Entra ID in quella finestra. Non serve altro per aprire un incidente.

La quarta mossa, meno tecnica, è la più trascurata: ruotare le credenziali che potrebbero essere state usate. Se la caccia nei log mostra anche un solo accesso sospetto, le password degli account coinvolti vanno cambiate e i token di sessione revocati; se non mostra nulla, ma il firewall è rimasto esposto a lungo senza telemetria adeguata, la rotazione preventiva degli account locali e di servizio costa un pomeriggio e vale la tranquillità. E vale la pena approfittarne per fare quello che andava fatto comunque: segmentare la rete in modo che una sessione VPN non equivalga a una scrivania in sede con accesso a tutto.

Come si torna in quella riunione, e cosa dice la norma

Il reparto IT che deve tornare davanti al CdA ha davanti due strade. La prima è la difesa d’ufficio: “era una vulnerabilità del vendor, serviva comunque una password, abbiamo patchato entro le scadenze”. È tutto vero ed è tutto insufficiente, perché descrive l’incidente come un evento atmosferico.

La seconda strada è quella che un consiglio maturo dovrebbe pretendere: “avevamo dichiarato l’MFA su un perimetro che non controllavamo per intero; la falla ha reso visibile una configurazione che era già debole; ecco l’inventario dei metodi di accesso, ecco cosa abbiamo chiuso, ecco cosa resta aperto e perché”.

La seconda versione è più scomoda per chi la pronuncia e infinitamente più utile per chi la ascolta. Il sarcasmo, qui, non va alle persone che hanno creduto alla prima frase: va a un sistema in cui “abbiamo l’MFA” è una voce di checklist e non una domanda sui percorsi.

Sul piano normativo il discorso è meno filosofico. Per i soggetti che rientrano nel perimetro NIS2, recepita in Italia con il D.Lgs. 138/2024, l’articolo 24 impone misure di gestione del rischio che includono esplicitamente la sicurezza della catena di approvvigionamento e la gestione delle vulnerabilità, inclusa la loro divulgazione.

Un apparato di accesso remoto fornito da un terzo, gestito spesso da un altro terzo, con una vulnerabilità pubblica e sfruttata, è il caso di scuola di rischio lato fornitore che la norma chiede di presidiare: non basta avere il firewall, bisogna avere il processo che legge gli avvisi del produttore, valuta l’esposizione e applica la correzione in tempi coerenti con la gravità.

Un firewall SonicWall ancora sulla versione vulnerabile a dicembre non è un ritardo tecnico, è un’evidenza documentale di mancanza del processo.

L’articolo 23 dello stesso decreto sposta il peso dove deve stare: gli organi di amministrazione approvano le misure di gestione del rischio, ne sorvegliano l’attuazione e sono tenuti a formarsi in materia. La conseguenza pratica è che un consigliere non può più limitarsi ad annuire alla frase rassicurante. Deve essere in grado di porre la domanda successiva, e se non lo è, la norma gli dice di imparare a farlo.

Se poi dal bypass deriva un incidente con impatto significativo, scattano gli obblighi di notifica dell’articolo 25, con il preallarme entro 24 ore e la notifica entro 72, e il tempo per raccontarsi che “serviva comunque una password” finisce molto in fretta.

Fuori dal perimetro NIS2 resta il GDPR, che non ha mai smesso di valere. L’articolo 32 chiede misure adeguate al rischio, e una VPN che dichiara MFA ma ne consente l’elusione è difficilmente qualificabile come adeguata una volta che la falla è pubblica.

Se da quell’accesso deriva una violazione di dati personali soggetta a notifica, l’articolo 33 impone di avvisare il Garante entro 72 ore dalla conoscenza, e il Garante vorrà sapere quando l’azienda ha appreso dell’avviso SonicWall e cosa ha fatto nei giorni successivi.

Per una PMI senza NIS2 addosso, il GDPR è spesso l’unico motivo giuridico per cui qualcuno chiederà conto della data del patch. È un motivo sufficiente.

La domanda da portare in consiglio

SonicWall ha fatto quello che un vendor deve fare: ha pubblicato, ha classificato con onestà, ha rilasciato la correzione senza offrire scorciatoie che non esistono.

CISA ha fatto la sua parte in giornata. Il resto, da qui al 20 novembre e oltre, è responsabilità di chi quegli apparati li possiede, li gestisce o li paga. Il firmware si aggiorna in un’ora. Il processo che avrebbe dovuto trovare da solo gli account locali dimenticati richiede più tempo, e soprattutto richiede che qualcuno, ai piani alti, smetta di accontentarsi della parola “attivato”.

La domanda non è se la vostra VPN ha l’MFA. La domanda è: quante strade portano dentro, e su quante di esse il secondo fattore è davvero obbligatorio? Se la risposta arriva in meno di dieci secondi, probabilmente nessuno ha mai contato.