La vulnerabilità CVE-2026-19868 di SonicOS mette in evidenza un problema più generale del singolo firewall: un controllo di autenticazione è efficace soltanto se ogni percorso che porta alla stessa risorsa lo rispetta. Si può aver configurato correttamente un identity provider, attivato la verifica a più fattori e continuare ad avere una strada alternativa che non attraversa nessuno dei due. Non è un difetto teorico di SAML: è un problema di applicazione coerente della policy nel punto in cui si concede l’accesso.
Che cosa è stato confermato
L’advisory SonicWall SNWLID-2026-0014 descrive una vulnerabilità nel servizio SSL VPN di SonicOS: chi dispone di credenziali valide per un metodo di autenticazione alternativo può aggirare i controlli SAML e, di conseguenza, la MFA imposta attraverso SAML. La condizione è importante. Non significa che chiunque possa entrare senza credenziali, né che ogni installazione SonicWall sia vulnerabile. Il problema riguarda il servizio SSL VPN quando SAML è abilitato per i login e il firmware è tra quelli interessati.
Il 6 novembre 2026 la CISA ha inserito CVE-2026-19868 nel catalogo Known Exploited Vulnerabilities. SonicWall ha dichiarato di aver indagato una segnalazione di possibile sfruttamento. Sono due formulazioni diverse: l’inclusione nel KEV indica evidenze di sfruttamento secondo CISA, mentre l’advisory del produttore non pubblica una ricostruzione completa degli attacchi. Non conosciamo da queste fonti il numero delle organizzazioni colpite né la catena operativa degli aggressori.
Il secondo percorso conta quanto il primo
Immaginiamo un accesso VPN in cui il login ordinario passa da un identity provider SAML con MFA. L’amministratore vede un controllo forte e può ragionevolmente pensare che l’accesso remoto sia protetto. Ma la domanda di sicurezza non è se il percorso principale chieda un secondo fattore. È se il dispositivo rifiuti qualunque sessione che non abbia soddisfatto la medesima policy.
Quando il sistema accetta un metodo alternativo con credenziali valide senza applicare la condizione SAML, il requisito MFA non è più un’invariante dell’accesso: diventa una proprietà di uno dei possibili flussi. Questo è il punto tecnico che rende interessante il caso anche a chi non gestisce firewall SonicWall. Il medesimo errore di modello può emergere in applicazioni con login locale residuo, API con credenziali storiche, accessi di emergenza o integrazioni migrate soltanto a metà.
La sicurezza di un accesso non si misura dal percorso più protetto, ma dal percorso meno protetto che il sistema continua ad accettare.
Chi deve intervenire e con quali versioni
Per Gen7 l’advisory indica come interessate le versioni SonicOS 7.3.3-7015 e precedenti e come corretta la 7.3.4-7013 o successiva. Per Gen8 sono interessate 8.2.2-8015 e precedenti; la correzione è in 8.2.3-8015 o successiva. La condizione specifica di questa CVE è SAML abilitato per SSL VPN. Le release correggono anche altre vulnerabilità, quindi l’assenza di SAML non equivale a una ragione generale per ignorare gli aggiornamenti.
Non è indicato un workaround ufficiale sostitutivo della patch. Per le agenzie federali civili statunitensi il catalogo CISA riporta la scadenza del 20 novembre 2026. Non è una scadenza normativa universale per le aziende italiane: è però un segnale concreto per dare priorità all’intervento.
Una verifica che non si ferma alla versione
Il primo controllo è un inventario: modello, generazione, build completa di SonicOS, presenza del servizio SSL VPN, configurazione SAML e metodi alternativi effettivamente abilitati. Senza questo incrocio si rischia sia di sottovalutare un’esposizione sia di classificare come compromesso un sistema che non soddisfa le condizioni della CVE.
Il secondo controllo è aggiornare alle release corrette secondo le indicazioni del produttore, verificando backup della configurazione e finestra di manutenzione. Il terzo è esaminare gli accessi VPN, gli account utilizzabili e gli eventi dell’identity provider. Confrontare sessioni VPN e autenticazioni SAML può far emergere discrepanze da approfondire, ma non costituisce da solo una prova di compromissione: logging incompleto, ritardi e altri percorsi autorizzati possono produrre differenze.
Infine serve una verifica funzionale: non basta osservare che la schermata di login propone MFA. Occorre controllare, con test autorizzati e account di prova, che ogni modalità consentita per raggiungere la stessa risorsa soddisfi i requisiti di accesso previsti. È un lavoro di configurazione e di architettura, non soltanto di aggiornamento.
La lezione per chi progetta sistemi
Il caso SonicOS distingue bene tre attività spesso confuse: attivare un controllo, renderlo obbligatorio e dimostrare che non esistono eccezioni involontarie. Il primo passaggio è visibile in console. Il secondo richiede che la policy sia applicata nel punto decisivo. Il terzo richiede inventario, test e osservabilità.
È la stessa disciplina che dovrebbe accompagnare una migrazione verso SSO, l’introduzione di MFA o la dismissione di autenticazioni legacy. Aggiungere un sistema di identità più sofisticato senza chiudere o governare i vecchi percorsi può aumentare la complessità senza produrre la protezione attesa.
Per chi amministra SonicWall l’azione immediata resta verificare la configurazione e applicare l’aggiornamento. Per chi progetta software e infrastrutture, la domanda da portarsi dietro è più duratura: quanti modi esistono davvero per ottenere quella sessione, e chi garantisce che tutti rispettino la stessa regola?
Domande frequenti
Domande frequenti
CVE-2026-19868 permette di accedere senza conoscere alcuna password?
No. SonicWall descrive un bypass dei controlli SAML per chi possiede credenziali valide di un metodo alternativo. Non è un accesso anonimo.
La vulnerabilità riguarda tutte le SSL VPN SonicWall?
No. Questa CVE riguarda il servizio SSL VPN nelle configurazioni con SAML abilitato e versioni SonicOS interessate. L’advisory comprende anche altre vulnerabilità.
Quali versioni SonicOS correggono il problema?
Gen7: 7.3.4-7013 o successiva. Gen8: 8.2.3-8015 o successiva. Verificare sempre modello e advisory ufficiale.
La scadenza CISA del 20 novembre vale per le aziende italiane?
È la scadenza indicata nel catalogo KEV per le agenzie federali civili statunitensi, non un obbligo generale italiano. Lo sfruttamento segnalato giustifica comunque un intervento prioritario.