Il 6 ottobre 2026 SonicWall ha pubblicato l'avviso SNWLID-2026-0017 per le appliance SMA 1000 (modelli SMA 6210, 7210 e 8200v) e tre giorni dopo, il 9 ottobre, un ricercatore ha riferito di aver visto tentativi di sfruttamento della falla più grave, CVE-2026-102255, valutata CVSS 10.0 dal produttore. È il terzo server-side request forgery (SSRF) senza autenticazione sulla stessa interfaccia in poco più di tre mesi, e riguarda prodotti che molte organizzazioni hanno già aggiornato a settembre credendo di aver chiuso la questione. Questo articolo è un aggiornamento della nostra copertura precedente: abbiamo raccontato le due falle di luglio e quelle di inizio settembre.

I fatti verificati

La vulnerabilità risiede nell'interfaccia Appliance WorkPlace, il portale con cui gli utenti raggiungono le risorse aziendali attraverso l'SMA 1000. SonicWall la descrive come un "percorso di accesso alternativo non previsto": un attaccante remoto e non autenticato può indurre l'appliance a inviare richieste per proprio conto, raggiungendo funzioni interne altrimenti non esposte. Il produttore non ha spiegato quali funzioni siano raggiungibili; l'impatto reale dipende quindi da ciò che l'appliance "vede" dall'interno della rete.

Lo stesso aggiornamento corregge altre tre vulnerabilità, tutte autenticate: CVE-2026-102256 (command injection a livello di sistema operativo, richiede privilegi di amministratore), CVE-2026-102257 (Zip Slip, scrittura di file fuori dalla cartella di estrazione nella console di gestione, potenzialmente utile per eseguire codice) e CVE-2026-102258 (XSS persistente nella console).

Le versioni vulnerabili sono quelle fino a 12.4.3-03526 e 12.5.0-02952 incluse, cioè proprio le build rilasciate a settembre. Non sono coinvolti gli SMA 100 e le funzioni SSL-VPN dei firewall SonicWall. Le fonti consultate non concordano sul numero di build correttive: l'avviso ripreso dal CSA di Singapore indica 12.4.3-03453 e 12.5.0-02835, mentre l'analisi di Field Effect e di Rescana indica 12.4.3-03670 e 12.5.0-03082. Le prime sono le build di luglio, quindi più vecchie di quelle vulnerabili: la lettura coerente è la seconda. In ogni caso, prima di intervenire va verificato il numero di build sull'avviso ufficiale SNWLID-2026-0017.

Sullo sfruttamento il quadro è sfumato. Al momento della pubblicazione SonicWall non segnalava attacchi e la falla non risultava nel catalogo KEV della CISA. Il 9 ottobre Ryan Dewhurst (Previdian) ha però riferito a BleepingComputer che la sua rete di honeypot ha registrato richieste mirate all'interfaccia WorkPlace Extraweb: una richiesta OPTIONS costruita per raggiungere il database CouchDB interno dell'appliance (127.0.0.1, porta 5984), con credenziali di default nell'intestazione. Non è noto se questi tentativi avrebbero avuto successo. Si tratta quindi di scansione e tentativi osservati, non di compromissioni confermate.

Cosa significa per le aziende italiane

Il punto più interessante non è il singolo CVE, ma il ritmo. Tre SSRF pre-autenticazione sulla stessa superficie in un trimestre indicano un problema di progettazione dell'interfaccia, non un bug isolato. Per chi gestisce l'appliance, la conseguenza pratica è che "siamo aggiornati a settembre" non è più una risposta valida: la build di settembre è esattamente quella vulnerabile. Un controllo di patch management basato su "ultimo avviso letto" fallisce, serve un controllo sul numero di build effettivo.

Il secondo aspetto riguarda il contesto di rischio. Le SMA 1000 sono apparecchiature di accesso remoto tipiche di aziende medio-grandi, enti pubblici locali e fornitori di servizi gestiti, che le usano per dare accesso ai propri clienti. Shadowserver ne conta oltre 400 esposte in Internet a livello globale, un numero modesto ma concentrato su organizzazioni con reti interne estese. Dopo gli attacchi di luglio, la CISA ha collegato parte dello sfruttamento a gruppi ransomware, e nel nostro precedente articolo su INC Ransomware abbiamo visto come l'accesso VPN rubato sia una porta d'ingresso ricorrente. Per un soggetto italiano la domanda è semplice: se l'appliance cade, quali credenziali e quali segmenti di rete si trovano dietro?

Il terzo aspetto è la catena di fornitura. Un MSP che usa SMA 1000 per accedere ai sistemi dei clienti trasferisce il proprio rischio sui clienti. Chi è cliente dovrebbe chiedere evidenza della build in uso e dell'esposizione del portale.

Contesto normativo

Per i soggetti NIS2 (essenziali e importanti) la gestione delle vulnerabilità e la sicurezza dell'accesso remoto rientrano tra le misure di sicurezza di base richieste dalla normativa e dalle determinazioni ACN: ricordiamo che la scadenza del 31 ottobre 2026 per gli adempimenti di base è vicina. Una compromissione di un apparato di accesso remoto che porti a un accesso non autorizzato a dati personali può inoltre configurare un data breach ai sensi del GDPR, con obbligo di valutazione e, se dovuto, notifica al Garante entro 72 ore da quando se ne ha conoscenza. Per i soggetti NIS2 vale anche la notifica di incidenti significativi al CSIRT Italia (preallarme entro 24 ore). Non è un obbligo "automatico" per il solo fatto di avere l'appliance vulnerabile: scatta se c'è un incidente. Ma documentare il controllo e la tempistica del patching è il modo per dimostrare diligenza.

Cosa fare subito

  • Identificare tutte le SMA 6210, 7210 e 8200v e verificare la build completa (non solo il ramo 12.4.3 o 12.5.0).
  • Aggiornare alla build corretta indicata nell'avviso SNWLID-2026-0017; non esiste una mitigazione alternativa nelle fonti consultate.
  • Limitare l'accesso al portale WorkPlace e alla console di gestione a reti e utenti fidati; valutare se il portale deve davvero essere raggiungibile da Internet.
  • Restringere il traffico in uscita dell'appliance ai soli servizi necessari e segmentare la rete di accesso remoto dai sistemi di amministrazione.
  • Controllare i log di WorkPlace per richieste OPTIONS anomale, connessioni in uscita insolite e modifiche di configurazione; per le ondate precedenti, chiedere al supporto SonicWall una verifica degli indicatori di compromissione.
  • Se emergono segni di compromissione: ripristinare o reinstallare l'appliance, cambiare tutte le password e reimpostare i token TOTP, come raccomanda SonicWall.
  • Chiedere ai fornitori che accedono ai vostri sistemi con SMA 1000 la conferma di build e verifiche eseguite.