SonicWall SMA 1000 CVE-2026-102255: SSRF pre-auth, CVSS 10
SonicWall corregge CVE-2026-102255, SSRF pre-auth CVSS 10 nella Work Place dell'SMA 1000. Nessuno sfruttamento — ma a luglio lo stesso apparato finì a root.
Pubblicato da Zero Hunt, un red team AI autonomo su un'appliance on-premise con AI privata: penetration test automatizzato per reti e infrastrutture, in black box o gray box, con una persona che approva ogni passo che conta.
Il 7 ottobre 2026 SonicWall ha rilasciato gli hotfix per quattro vulnerabilità dei suoi apparati di accesso sicuro SMA 1000, e una di esse è un server-side request forgery pre-autenticazione di severità massima: CVE-2026-102255, con punteggio CVSS 10.0. Un attaccante non autenticato, da Internet, può costringere l'apparato a emettere richieste per suo conto e raggiungere funzionalità interne che si fidano di esso. SonicWall dichiara che non ci sono ancora prove di sfruttamento. È proprio quell'ancora il cuore di questo articolo: la stessa interfaccia Work Place dell'SMA 1000, tre mesi fa, portava un SSRF CVSS 10.0 che dalla divulgazione allo sfruttamento attivo fino a root passò nel giro di poche ore.
Notizia in evoluzione — pubblicata alle 13:55 (11:55 UTC) del 2026-10-07. Aggiornata man mano che SonicWall e CISA pubblicano.
In breve
| CVE | CVE-2026-102255 (record NVD non ancora pubblicato al 2026-10-07) |
| Prodotto / versioni colpite | SMA 1000 serie 6210 · 7210 · 8200v (fisici e virtuali); serie SMA 100 e SSL-VPN dei firewall non interessate |
| Corretta in | 12.4.3-03670 e successive; 12.5.0-03082 e successive (hotfix, 2026-10-07) |
| CVSS | 10.0 · Critica (SonicWall; NVD non ancora assegnato) |
| Sfruttata attivamente | Nessuna prova al 2026-10-07 (dichiarazione nell'advisory SonicWall) |
| CISA KEV | Non presente (versione catalogo 2026.10.04) |
| PoC pubblico | Nessuno pubblico al 2026-10-07 secondo le fonti |
| Advisory ufficiale | SonicWall SNWLID-2026-0017 |
Cosa ha corretto davvero SonicWall
La falla principale, CVE-2026-102255, è un SSRF pre-autenticazione nell'interfaccia Work Place dell'SMA 1000 — il portale che termina le sessioni di accesso remoto e che per progettazione guarda verso Internet. SonicWall la descrive come un "percorso di accesso alternativo non previsto" che consente a un attaccante remoto e non autenticato di "costringere l'apparato a emettere richieste per suo conto e raggiungere funzionalità interne ed eseguire operazioni non autorizzate", stando alla dichiarazione del vendor riportata da Help Net Security. L'SSRF vale il 10.0 pieno perché non richiede credenziali, né interazione dell'utente, e la posizione dell'apparato sul confine di fiducia fa sì che "funzionalità interne" non sia una sandbox: è il piano di gestione e i servizi che il gateway già raggiunge.
Le altre tre, stesso advisory, richiedono tutte un amministratore autenticato e perciò valgono meno:
- CVE-2026-102256 — OS command injection post-autenticazione nella console di gestione (CVSS 7.8).
- CVE-2026-102257 — un path traversal "Zip Slip" che arriva all'esecuzione di codice remoto tramite un archivio malevolo (CVSS 7.2).
- CVE-2026-102258 — cross-site scripting memorizzato nell'Appliance Management Console (CVSS 5.5).
La lezione dell'incidente di luglio su questo apparato è che "richiede admin" non è il freno che sembra. A luglio SonicWall corresse CVE-2026-15409 e CVE-2026-15410 — un SSRF CVSS 10.0 nella Work Place concatenato a una code injection "solo per admin" — ed entrambi erano già sfruttati in incidenti reali. L'SSRF portava l'attaccante dentro il confine di fiducia, che è esattamente ciò che rende raggiungibile un bug post-auth. Quella catena l'avevamo analizzata all'epoca nel nostro approfondimento SSRF-to-root sull'SMA1000. CVE-2026-102255 è la stessa primitiva sulla stessa interfaccia, stavolta intercettata prima della weaponizzazione.
Chi è esposto, e come verificare
Shadowserver censisce oltre 400 apparati SMA 1000 esposti su Internet, e BleepingComputer ricorda che CISA ha catalogato nel tempo 19 vulnerabilità SonicWall come sfruttate, 13 delle quali legate a ransomware. Se gestite uno dei modelli colpiti, trattatela come un'emergenza di perimetro anche senza segnalazioni di sfruttamento: su questo prodotto la finestra tra divulgazione e sfruttamento è stata storicamente breve.
Controllate la build in esecuzione dalla console dell'apparato o dal Central Management Server:
- SMA 1000 standalone: System → Status, leggete la stringa del firmware (es.
12.4.3-03xxxo12.5.0-02xxx). - Qualsiasi build sul ramo 12.4.3 sotto
-03670, o sul ramo 12.5.0 sotto-03082, è vulnerabile.
Remediation
- Sono colpito? Verificate che il modello sia 6210, 7210 o 8200v e leggete la build del firmware. La serie SMA 100 e l'SSL-VPN sui firewall SonicWall non rientrano in questo advisory: non aggiornate la flotta sbagliata cantando vittoria.
- Patch — versioni corrette esatte. Applicate l'hotfix: 12.4.3-03670 e successive sul ramo 12.4.3, 12.5.0-03082 e successive sul ramo 12.5.0. Non è documentato alcun workaround; l'aggiornamento è la correzione.
- Non potete patchare subito? Riducete la portata dell'SSRF. Un SSRF è pericoloso quanto ciò che l'apparato può contattare. Mettete l'SMA 1000 in un segmento con egress rigorosamente in allow-list — deve raggiungere i back-end di autenticazione e i servizi che fa da proxy, e nient'altro. Negategli l'accesso in uscita verso gli endpoint di metadati cloud (
169.254.169.254), verso la rete di gestione e verso le interfacce admin interne. Non corregge il bug; limita ciò che una richiesta forzata può colpire (MITRE ATT&CK T1190, accesso iniziale via applicazione esposta). - Cercate abusi della finestra. Non esistono IOC pubblicati dal vendor per CVE-2026-102255 perché non c'è sfruttamento osservato — quindi cercate sul comportamento, non sulle firme. Il segnale di un SSRF abusato è l'apparato che origina connessioni che normalmente non fa mai: richieste in uscita dall'IP dell'SMA 1000 verso host interni, verso servizi di loopback locali, o verso endpoint di metadati. Estraete i log di flusso in egress dell'apparato e il netflow del gateway e cercate destinazioni interne mai viste prima nei giorni attorno alla divulgazione. Mappatelo a T1090 (proxy/traffico rilanciato): l'apparato diventa il relay.
- Bonificate e verificate. Se trovate che l'apparato ha emesso richieste che non dovrebbe mai originare, trattatelo come compromesso: snapshot per forense, ricostruzione da un'immagine nota e integra invece della patch in-place, e rotazione di ogni segreto che il gateway custodisce — credenziali admin, token API e gli account di servizio dei back-end di autenticazione che può raggiungere. Confermate la pulizia dopo la ricostruzione, non prima.
Cosa non si sa ancora
- Il vettore CVSS e la CWE — SonicWall ha pubblicato il punteggio 10.0; la stringa completa del vettore e l'analisi indipendente di NVD non erano disponibili alla pubblicazione.
- Se comparirà un PoC pubblico. Al momento non ne esiste alcuno. Dato il precedente di luglio sulla stessa interfaccia, date per scontato che il reverse engineering della patch sia già in corso.
- Eventuale sfruttamento. SonicWall dichiara nessuno; è un'istantanea, non una garanzia, e cambierà nel momento in cui un PoC funzionante colpirà oltre 400 apparati esposti.
Dove si colloca Zero Hunt
Una stringa di firmware vi dice se siete patchati. Non vi dice se l'SSRF pre-auth fosse raggiungibile sulla vostra installazione nella finestra precedente alla patch, né se qualcuno ci sia passato. Senza un PoC pubblico, l'unico modo onesto per rispondere è dimostrarlo sul proprio apparato prima che lo faccia un attaccante.
È ciò che fa il red team autonomo con AI di Zero Hunt contro un apparato di perimetro come l'SMA 1000: uno swarm di 10 agenti opera in black-box contro il dispositivo reale sul perimetro e, quando l'identificazione esatta di prodotto e versione indica una debolezza raggiungibile, un agente di coding sigillato scrive un proof-of-concept per quel bersaglio — un modello locale sull'apparato on-premise, nessun exploit pubblico da attendere, nessun codice che lascia la macchina — e itera finché l'SSRF raggiunge dimostrabilmente le funzionalità interne oppure dimostrabilmente no. Ogni passo gira in un container effimero con un umano nel loop che autorizza qualsiasi azione che tocchi il gateway in produzione, e ogni evidenza è firmata al momento della scrittura. Una campagna attivata dal cambiamento riparte nel momento in cui un nuovo apparato compare sul perimetro — esattamente la cadenza che gli attaccanti di luglio hanno usato contro questo stesso prodotto.
Il secondo punto cieco è la rilevazione durante la finestra silenziosa. Un SSRF pre-auth non lascia malware e non fa scattare alcuna firma; il suo unico segnale è l'apparato che improvvisamente si comporta da relay verso la rete che dovrebbe proteggere. L'AI Traffic Analysis di Zero Hunt — un modello di deep learning con quattro teste di inferenza, addestrato su miliardi di sequenze PCAP e in esecuzione sulla GPU dell'apparato a oltre 2,7 Gbit/s — profila come appare l'egress normale del vostro gateway e segnala l'apparato che origina richieste interne mai viste prima, mentre sta accadendo, non nel digest del SIEM del mattino dopo.
Se vi serve l'inquadramento normativo dei doveri di test sugli apparati di perimetro, la nostra guida al penetration testing automatizzato spiega come la validazione black-box continua si mappi sugli obblighi di test che ormai quasi tutti i framework prevedono.
Tutte le vulnerabilità che CISA segnala come sfruttate, con le scadenze federali: tracker CISA KEV →
È sfruttabile nel tuo ambiente?
Zero Hunt lo verifica sulla tua rete: un red team AI autonomo su un'appliance on-premise, con AI privata, in black box o gray box e con una persona che approva ogni passo che conta. La prova di cosa è sfruttabile, la correzione e le evidenze firmate — nessun dato esce dal tuo perimetro.