Sette settimane fa avevamo raccontato due zero-day sfruttate attivamente sulle appliance SonicWall SMA 1000, concatenate per rubare credenziali, database di sessione e seed TOTP. Il 2 settembre 2026 SonicWall ha pubblicato l'advisory SNWLID-2026-0016: due nuove vulnerabilità, sugli stessi apparati, sfruttate in rete, con lo stesso identico schema di attacco. Non è un aggiornamento della vicenda di luglio — sono falle diverse, con identificativi diversi — ma leggere i due episodi separatamente significa perdere il punto.

Cosa è successo

Le vulnerabilità sono due e vengono usate in catena.

CVE-2026-83548 è una Server-Side Request Forgery pre-autenticazione nell'interfaccia Appliance WorkPlace, quella esposta agli utenti che si collegano. È di gravità massima e consente a un attaccante remoto non autenticato di ottenere accesso a funzionalità sensibili ed eseguire operazioni non previste.

CVE-2026-83549 è una OS command injection nella Appliance Management Console: in condizioni specifiche permette a un attaccante con privilegi amministrativi di eseguire comandi arbitrari sul sistema operativo dell'appliance, quindi codice remoto sul dispositivo.

Messe insieme, la prima apre la breccia senza credenziali e la seconda la converte in esecuzione di comandi. Chi segue questi apparati avrà notato la sovrapposizione: è la stessa struttura di CVE-2026-15409 e CVE-2026-15410 di luglio, SSRF pre-auth più command injection post-auth sui due componenti gemelli. Le due falle sono state individuate internamente da William Perry e Adam Babis di SonicWall.

Sono interessati i modelli SMA 1000 6210, 7210 e 8200v, sia fisici sia virtuali. Non sono interessati gli apparati SMA serie 100 né la SSL-VPN dei firewall SonicWall — distinzione importante, perché nel parco italiano i firewall SonicWall con SSL-VPN sono molto più numerosi delle SMA 1000.

SonicWall non ha pubblicato indicatori di compromissione né dettagli sugli attacchi in corso. Ha però indicato la procedura in caso di compromissione accertata: reinstallare l'immagine (per gli apparati fisici) o ridistribuire (per i virtuali), cambiare tutte le password di utenti e amministratori, e azzerare i token TOTP. È una raccomandazione che vale la pena leggere per quello che implica: non si chiede di reinstallare un apparato per una compromissione superficiale.

Secondo Shadowserver, sono oltre 400 le appliance SMA 1000 raggiungibili da Internet al momento dell'advisory — alcune, presumibilmente, già aggiornate.

Cosa significa per le aziende italiane

Il primo punto è di posizionamento: la SMA 1000 non è il prodotto SonicWall della piccola impresa. È la linea per grandi organizzazioni, pubbliche amministrazioni e fornitori di servizi gestiti, progettata per scalare su molte sessioni concorrenti. In Italia questo significa aziende strutturate, enti, ospedali, e soprattutto MSP che con un solo apparato servono decine di clienti. Un gateway di accesso remoto di un fornitore di servizi gestiti compromesso non è un incidente del fornitore: è un incidente di tutti i suoi clienti contemporaneamente, ed è esattamente il tipo di scenario che NIS2 chiama rischio della catena di fornitura.

Il secondo punto è quello che conta davvero, e vale la pena dirlo senza giri di parole: se la vostra SMA 1000 è stata esposta a luglio, applicare l'hotfix di settembre non chiude la partita. Nella catena precedente gli attaccanti esfiltravano credenziali, database delle sessioni attive e seed TOTP. Un seed TOTP rubato consente all'attaccante di generare autonomamente i codici a sei cifre validi di quell'utente, per sempre, finché il seed non viene rigenerato. La patch chiude la porta; non revoca le chiavi già consegnate. Ad agosto la CISA statunitense ha confermato che gruppi ransomware hanno iniziato ad abusare delle falle di luglio, e Resecurity e Rapid7 hanno attribuito quegli attacchi a INC Ransomware: se la finestra di esposizione non è stata seguita da una rotazione completa di password e token, il rischio non è teorico. È la stessa dinamica vista con Ivanti, Citrix e Fortinet negli ultimi anni, ed è il motivo per cui gli attaccanti oggi puntano sui gateway più che sui server interni.

Il terzo punto è che tre catene di zero-day in nove mesi sullo stesso prodotto smettono di essere sfortuna e diventano un dato di pianificazione. Dopo CVE-2025-40602 di dicembre, la coppia di luglio e ora questa, chi ha una SMA 1000 in produzione dovrebbe assumere come ipotesi di lavoro che ci sarà un'altra catena, e organizzarsi di conseguenza: procedura di aggiornamento d'emergenza già scritta e provata, non improvvisata alle due di notte; monitoraggio continuo dei log dell'apparato verso un SIEM esterno, perché i log che restano solo sull'apparato compromesso non servono a nulla; e una valutazione onesta, con tempi realistici, sull'opportunità di restare su questa piattaforma.

Il quarto punto riguarda una scelta architetturale che questo caso illustra bene. Il componente vulnerabile pre-autenticazione è il WorkPlace, cioè il portale rivolto agli utenti. È necessariamente esposto: è la porta d'ingresso. Ma la Management Console — la seconda metà della catena — non ha alcuna ragione di essere raggiungibile da Internet. Separare i due piani, limitando l'accesso amministrativo a una rete di gestione o a una allowlist di indirizzi, non elimina la prima falla ma spezza la catena, che è ciò che trasforma un accesso non autenticato in esecuzione di codice. Vale la pena verificare come è configurato il proprio apparato prima di scoprirlo durante un'analisi forense.

Il contesto normativo

Un gateway VPN compromesso è, sul piano regolatorio, uno degli scenari peggiori: è il punto da cui si accede a tutto il resto. Per i soggetti in perimetro NIS2, un accesso non autorizzato al concentratore di accesso remoto è quasi automaticamente un incidente significativo, con pre-allarme al CSIRT Italia entro 24 ore e notifica completa entro 72 ore. Il termine decorre da quando si acquisisce consapevolezza, e va sottolineato che l'obbligo scatta anche in assenza di certezza sull'impatto: nel dubbio, il pre-allarme si manda.

Per un MSP, che rientra fra i soggetti importanti in quanto fornitore di servizi gestiti, si aggiunge il dovere di informare i clienti impattati. La gestione della sicurezza della catena di fornitura ICT è fra le misure minime dell'articolo 24 del D.lgs. 138/2024, e un gateway condiviso è il caso di scuola.

Sul piano GDPR, se attraverso la VPN transitano accessi a sistemi che trattano dati personali — e nella pratica è così — l'esfiltrazione di credenziali e sessioni configura una violazione da valutare ai sensi dell'articolo 33, con l'orologio delle 72 ore verso il Garante. Un dettaglio pratico spesso trascurato: il furto dei seed TOTP costituisce di per sé una violazione di dati di autenticazione degli interessati coinvolti, indipendentemente da quali dati siano stati poi effettivamente raggiunti.

Per le entità finanziarie soggette a DORA, l'accesso remoto rientra fra i sistemi ICT critici: incidente da classificare secondo i criteri del regolamento e, se grave, da segnalare all'autorità competente.

Cosa fare subito

  • Installare l'hotfix più recente per SMA 1000 6210, 7210 e 8200v, fisici o virtuali, senza attendere la finestra di manutenzione ordinaria. Le falle sono sfruttate ora.
  • Contattare il supporto tecnico SonicWall per la verifica degli indicatori di compromissione: al momento il vendor non ha pubblicato IoC, e l'analisi va fatta con loro.
  • Se la compromissione è confermata: reinstallare l'immagine dell'apparato fisico o ridistribuire quello virtuale, cambiare tutte le password di utenti e amministratori e rigenerare i token TOTP. Non è una raccomandazione prudenziale: è la procedura indicata dal vendor.
  • Se l'apparato era esposto durante la finestra di luglio-agosto e non avete già ruotato credenziali e seed TOTP, fatelo ora a prescindere da questo advisory. La patch di settembre non annulla quello che è stato rubato a luglio.
  • Togliere la Management Console da Internet, limitandone l'accesso a una rete di gestione dedicata o a una allowlist. È la misura che spezza la catena di attacco.
  • Rivedere i log di autenticazione e di sessione cercando accessi da indirizzi anomali, sessioni concorrenti impossibili per lo stesso utente, autenticazioni riuscite fuori dagli orari abituali. Se i log non sono esportati verso un sistema esterno, questa è l'occasione per farlo.
  • Considerare l'invalidazione forzata di tutte le sessioni attive dopo l'aggiornamento: un token di sessione rubato resta valido finché non lo si revoca esplicitamente.
  • Verificare l'esposizione reale del proprio apparato da Internet, e in generale chiedersi quali altre interfacce amministrative siano raggiungibili senza che sia stata una decisione consapevole.