Due vulnerabilità zero-day nelle appliance SonicWall SMA1000 hanno permesso ad aggressori sconosciuti di violare reti aziendali in tutto il mondo per quasi un mese prima che l’azienda pubblicasse una patch. Rapid7 ha tracciato la prima attività ostile al 22 giugno 2026, tre settimane prima che SonicWall riconoscesse pubblicamente il problema il 14 luglio. Nel frattempo un gruppo di affiliati di INC Ransomware ha iniziato a sfruttare le stesse falle per muoversi lateralmente dentro le reti colpite, secondo un’analisi di Resecurity pubblicata il 10 agosto. La vicenda coinvolge direttamente le aziende europee: gli SMA1000 sono gateway di accesso remoto usati da grandi imprese, enti pubblici e fornitori di servizi gestiti per collegare migliaia di dipendenti da remoto.

Il caso mostra un modello che si ripete da anni nel settore degli apparati di accesso remoto aziendale: un difetto critico rimane sconosciuto per settimane, viene sfruttato da un attore sofisticato per lo spionaggio o l’accesso iniziale, e poco dopo la sua pubblicazione un gruppo ransomware lo adotta su scala più ampia. Con Shadowserver che a metà agosto contava ancora oltre 380 appliance SMA1000 esposte online, il rischio resta concreto anche per chi non ha ancora applicato l’hotfix.

Cosa sono le vulnerabilità zero-day di SonicWall SMA1000

SonicWall SMA1000 è una famiglia di appliance per l’accesso remoto sicuro, pensata per sostituire le VPN tradizionali con un portale centralizzato di autenticazione e proxy applicativo. I modelli coinvolti sono SMA 6210, SMA 7210 e SMA 8200v, diffusi tra medie e grandi organizzazioni che devono gestire l’accesso di centinaia o migliaia di utenti remoti. Il 14 luglio 2026 SonicWall ha reso pubbliche due vulnerabilità zero-day già sfruttate attivamente: CVE-2026-15409 e CVE-2026-15410. Non si tratta di difetti teorici scoperti da un ricercatore in laboratorio, ma di falle già usate contro clienti reali prima ancora che esistesse una correzione.

La combinazione delle due vulnerabilità permette a un aggressore di passare da zero privilegi a controllo completo dell’appliance, e da lì di entrare nella rete interna dell’organizzazione colpita. È esattamente lo schema che ha reso famose, negli ultimi anni, altre appliance VPN aziendali: un punto di accesso pensato per la sicurezza diventa la porta d’ingresso preferita dagli attaccanti.

CVE-2026-15409: la falla SSRF con punteggio CVSS 10.0

CVE-2026-15409 è una vulnerabilità di tipo server-side request forgery (SSRF) nell’interfaccia Workplace dell’appliance SMA1000. Il punteggio CVSS è 10.0, il massimo della scala, perché la falla non richiede alcuna autenticazione e consente l’esecuzione di codice da remoto. Secondo l’analisi tecnica di Tenable, l’aggressore sfrutta la funzione websocket proxy nota come wsproxy, esposta sulla porta 443, per aprire un tunnel verso servizi interni disponibili solo su localhost. Da lì può raggiungere il motore applicativo Erlang in ascolto sulla porta 1050 e ottenere l’esecuzione di comandi arbitrari.

In pratica, un attaccante senza credenziali può bussare alla porta pubblica dell’appliance e finire, in pochi passaggi, dentro componenti che dovrebbero essere raggiungibili solo dall’interno del dispositivo. È il tipo di scorciatoia architetturale che i team di sicurezza temono di più, perché elimina la necessità di rubare una password o superare l’autenticazione a due fattori.

CVE-2026-15410: l’iniezione di codice post-autenticazione

La seconda falla, CVE-2026-15410, ha una gravità classificata come alta con punteggio CVSS 7.2. A differenza della prima, richiede che l’aggressore disponga già di un accesso amministrativo alla console di gestione dell’appliance (Appliance Management Console). Una volta dentro, può sfruttare un difetto di path traversal nel flusso di lavoro remove_hotfix per ottenere l’esecuzione di comandi con privilegi root.

Le due vulnerabilità, prese singolarmente, sarebbero già gravi. Concatenate insieme, permettono a chi non ha alcun accesso di raggiungere in poche mosse il controllo completo del sistema operativo sottostante. Rapid7 ha documentato esattamente questo schema durante le sue indagini di risposta agli incidenti nel mese di luglio.

La cronologia dell’attacco: da giugno a agosto 2026

La ricostruzione temporale dell’incidente aiuta a capire quanto tempo gli aggressori abbiano avuto a disposizione prima che esistesse una patch pubblica. Il team di Rapid7 MDR ha individuato le prime tracce di sfruttamento circa tre settimane prima dell’annuncio ufficiale di SonicWall, un intervallo che ha dato agli attaccanti un vantaggio significativo su migliaia di reti aziendali.

DataEvento
22 giugno 2026Rapid7 rileva la prima attività ostile riconducibile all’attore UTA0533 contro appliance SMA1000
9 luglio 2026Viene osservata una seconda ondata di sfruttamento su un numero più ampio di dispositivi
14 luglio 2026SonicWall pubblica l’advisory ufficiale e l’hotfix; CISA aggiunge CVE-2026-15409 e CVE-2026-15410 al catalogo KEV
17 luglio 2026Scadenza fissata da CISA per l’applicazione della patch da parte delle agenzie federali statunitensi (FCEB)
10 agosto 2026Resecurity collega un affiliato di INC Ransomware allo sfruttamento successivo delle stesse falle
16 agosto 2026Shadowserver rileva ancora oltre 380 appliance SMA1000 esposte pubblicamente senza patch

La catena d’attacco tecnica passo dopo passo

Capire il meccanismo tecnico aiuta i responsabili IT a valutare l’urgenza reale della patch, non solo il punteggio CVSS astratto. La catena descritta da Tenable e da Rapid7 si sviluppa in tre fasi distinte.

Fase uno: accesso non autenticato via wsproxy

L’aggressore contatta la porta 443 dell’appliance, pubblicamente esposta perché è quella usata dagli utenti legittimi per connettersi. Attraverso la funzione wsproxy apre un tunnel websocket verso servizi interni pensati per restare isolati dalla rete esterna.

Fase due: esecuzione di codice tramite il motore Erlang

Una volta dentro, l’attaccante raggiunge il servizio applicativo basato su Erlang sulla porta 1050. Da qui ottiene l’esecuzione di codice con i privilegi del processo, un passaggio sufficiente per installare strumenti di persistenza sull’appliance.

Fase tre: escalation a root tramite remove_hotfix

Con un accesso amministrativo, anche minimo, l’aggressore sfrutta il path traversal nel flusso remove_hotfix per scrivere o eliminare file al di fuori delle directory previste, arrivando al controllo completo con privilegi di root. A questo punto l’appliance non è più un semplice punto di accesso compromesso: diventa una testa di ponte dentro la rete aziendale.

UTA0533 e i quattro malware personalizzati

Le indagini di Rapid7 hanno attribuito la prima ondata di attacchi a un attore tracciato come UTA0533. Il gruppo ha sviluppato e distribuito quattro famiglie di malware su misura per l’ambiente SMA1000, denominate KNUCKLEBALL, Sou5, ROOTRUN e ORANGETAIL. La varietà degli strumenti suggerisce un livello di preparazione tecnica superiore a quello di un normale gruppo criminale opportunista, con moduli distinti per la persistenza, l’esfiltrazione e il movimento laterale.

Durante le intrusioni, gli aggressori hanno sistematicamente estratto tre categorie di dati dall’appliance compromessa: credenziali degli utenti, database delle sessioni attive e semi (seed) usati per generare codici TOTP di autenticazione a due fattori. È un dettaglio che cambia il calcolo del rischio per chi gestisce questi apparati.

Perché il furto dei semi TOTP è più grave del solito

La maggior parte delle organizzazioni considera l’autenticazione a due fattori basata su codici temporanei (TOTP) una difesa solida contro il furto di credenziali. Se un aggressore ottiene solo la password, il secondo fattore blocca comunque l’accesso. Il problema, in questo caso, è diverso: gli attaccanti non hanno rubato un singolo codice temporaneo, ma il seed segreto usato per generarli.

Con il seed in mano, un aggressore può generare autonomamente codici TOTP validi in qualsiasi momento futuro, senza bisogno di intercettare nulla in tempo reale. In altre parole, il secondo fattore di autenticazione smette di essere un ostacolo. Rapid7 ha documentato casi in cui questo accesso è stato usato per pivotare verso l’infrastruttura Active Directory interna, sfruttando credenziali di dominio raccolte dalla stessa appliance compromessa.

Per le aziende colpite, questo significa che ruotare solo le password non basta. Serve rigenerare da zero i seed MFA di tutti gli utenti che si sono autenticati attraverso l’appliance nel periodo a rischio, un’operazione spesso trascurata perché più complessa di un semplice reset password.

Da zero-day a ransomware: l’ingresso di INC Ransomware

Il passaggio da spionaggio mirato a criminalità organizzata su larga scala è la seconda fase tipica di questi incidenti. Secondo l’analisi pubblicata da Resecurity il 10 agosto 2026 e ripresa da BleepingComputer, un affiliato riconducibile a INC Ransomware ha iniziato a sfruttare le stesse due CVE per ottenere accesso iniziale a reti aziendali, con l’obiettivo di distribuire ransomware ed estorcere le vittime.

Questo schema, in cui un exploit sviluppato o scoperto da un attore sofisticato finisce nell’arsenale di gruppi ransomware con finalità economiche, si è ripetuto più volte negli ultimi anni su appliance VPN aziendali. Una volta che un metodo d’accesso funziona ed è documentato pubblicamente, altri gruppi criminali lo replicano rapidamente, spesso nel giro di poche settimane dalla divulgazione.

Quante appliance restano esposte a metà agosto

Il monitoraggio indipendente condotto da Shadowserver Foundation, citato da Rapid7, contava oltre 380 appliance SMA1000 ancora raggiungibili pubblicamente su Internet senza la patch applicata, a più di un mese dalla pubblicazione dell’hotfix. Il numero comprende dispositivi in tutte le regioni del mondo, incluse organizzazioni europee che usano gli SMA1000 come punto d’accesso remoto principale per i propri dipendenti.

Il dato è significativo perché mostra un problema strutturale: anche quando esiste una patch pubblica, un catalogo ufficiale nel KEV di CISA e un’ampia copertura da parte della stampa specializzata, una quota consistente di appliance resta esposta. Le ragioni più comuni includono cicli di manutenzione lenti, la paura di interrompere l’accesso remoto durante l’orario lavorativo e, in alcuni casi, la semplice assenza di un inventario aggiornato dei dispositivi esposti su Internet.

L’inserimento nel catalogo CISA KEV e la scadenza federale

Il 14 luglio 2026, lo stesso giorno della disclosure di SonicWall, l’agenzia statunitense CISA ha aggiunto entrambe le CVE al proprio catalogo Known Exploited Vulnerabilities. L’inserimento nel KEV obbliga le agenzie federali civili statunitensi (FCEB) ad applicare la correzione entro una scadenza fissata, in questo caso appena tre giorni dopo, il 17 luglio 2026. È un termine estremamente stretto, che riflette la gravità assegnata al problema dagli analisti dell’agenzia.

Per le organizzazioni europee il KEV non ha valore vincolante diretto, ma è diventato negli ultimi anni un riferimento operativo anche fuori dagli Stati Uniti. Molti team di sicurezza italiani ed europei usano il catalogo come lista di priorità per le patch, indipendentemente dagli obblighi normativi locali imposti da normative come NIS2.

L’impatto sulle organizzazioni italiane ed europee

Gli SMA1000 sono diffusi tra aziende di medie e grandi dimensioni che hanno investito in infrastrutture di accesso remoto centralizzato, un segmento che in Italia comprende banche, assicurazioni, enti pubblici locali e fornitori di servizi gestiti che offrono connettività VPN in outsourcing a clienti terzi. Quest’ultimo punto amplifica il rischio: un singolo MSP compromesso può trasformarsi nel punto d’ingresso per decine di aziende clienti contemporaneamente.

Con il Cyber Resilience Act e la direttiva NIS2 già in vigore o prossimi alla piena applicazione, le aziende italiane soggette a questi obblighi devono dimostrare processi di gestione delle vulnerabilità documentati. Un’appliance SMA1000 non patchata, esposta pubblicamente per settimane dopo l’uscita della correzione, rappresenta esattamente il tipo di lacuna che gli auditor e le autorità di vigilanza, inclusa l’Agenzia per la Cybersicurezza Nazionale, tendono a segnalare nelle ispezioni.

Le versioni firmware corrette e il percorso di aggiornamento

SonicWall non ha lasciato spazio a soluzioni intermedie: non esiste alcuna mitigazione temporanea o workaround documentato per queste due vulnerabilità. L’unica risposta efficace è l’aggiornamento immediato alla versione firmware corretta, disponibile dal 14 luglio 2026.

Versione firmware vulnerabileVersione corretta consigliata
12.4.3-0324512.4.3-03453
12.4.3-0338712.4.3-03453
12.4.3-0343412.4.3-03453
12.5.0-0228312.5.0-02835
12.5.0-0262412.5.0-02835
12.5.0-0280012.5.0-02835

Oltre all’aggiornamento del firmware, gli analisti di Help Net Security raccomandano di trattare ogni SMA1000 esposto prima della patch come potenzialmente compromesso: rotazione completa delle credenziali amministrative, rigenerazione dei seed MFA e revisione dei log di autenticazione degli ultimi due mesi alla ricerca di sessioni anomale.

Confronto con altri zero-day recenti su appliance VPN aziendali

Il caso SonicWall non è isolato. Negli ultimi due anni, appliance di accesso remoto di diversi fornitori sono state colpite da zero-day con dinamiche simili: sfruttamento silenzioso prima della disclosure, adozione successiva da parte di gruppi ransomware, e una finestra di esposizione che si misura in settimane anche dopo l’uscita della patch. Il denominatore comune è l’architettura stessa di questi dispositivi: sono progettati per essere raggiungibili da Internet, il che li rende bersagli permanenti per la scansione automatizzata.

Un caso analogo, discusso nel nostro approfondimento sullo zero-day Ivanti EPMM, ha coinvolto quattro governi europei con una dinamica di sfruttamento pre-disclosure quasi identica. La lezione che se ne ricava è sempre la stessa: la presenza nel catalogo CISA KEV, di per sé, non riduce il rischio se le organizzazioni non riescono ad applicare le patch nei giorni immediatamente successivi alla pubblicazione.

Come verificare se la propria appliance è stata compromessa

Per i team di sicurezza che gestiscono SMA1000, la priorità immediata è distinguere tra “non ancora patchato” e “già compromesso”. Rapid7 suggerisce di controllare tre indicatori concreti prima di considerare l’incidente chiuso con il solo aggiornamento del firmware.

  • Connessioni websocket anomale verso la porta 443 con pattern non riconducibili a client VPN legittimi
  • Voci di log relative a operazioni sul flusso remove_hotfix eseguite fuori dalle normali finestre di manutenzione pianificata
  • Nuove sessioni amministrative aperte da indirizzi IP geograficamente incoerenti con la sede dell’organizzazione
  • Modifiche non tracciate ai file di configurazione dell’Appliance Management Console

In presenza anche di un solo indicatore, la raccomandazione degli analisti di eSentire è di trattare l’intero ambiente come compromesso, non solo l’appliance, avviando una risposta agli incidenti completa che includa il dominio Active Directory collegato.

Le lezioni per chi gestisce infrastrutture di accesso remoto

La vicenda SonicWall offre almeno tre indicazioni operative valide oltre il singolo prodotto coinvolto. Primo, la segmentazione interna conta più della fiducia riposta nel perimetro. Se un’appliance VPN compromessa può raggiungere direttamente Active Directory senza ulteriori controlli, l’intera rete eredita il rischio dell’appliance stessa. Secondo, il monitoraggio esterno della propria superficie d’attacco, quello che strumenti come Shadowserver rendono pubblico, dovrebbe far parte della routine di sicurezza, non essere scoperto passivamente tramite un articolo di stampa.

Terzo, e forse il più trascurato: il secondo fattore di autenticazione non è invulnerabile per definizione. Un seed TOTP rubato vale quanto una password permanente, e le organizzazioni dovrebbero pianificare la rotazione dei segreti MFA con la stessa serietà con cui pianificano quella delle password, specialmente dopo un incidente di questo tipo.

Previsioni: cosa aspettarsi nei prossimi mesi

Sulla base della dinamica osservata finora, si possono formulare alcune previsioni ragionevoli sull’evoluzione del caso SonicWall SMA1000 nei mesi successivi ad agosto 2026.

  1. Il numero di appliance non patchate scenderà gradualmente, ma è probabile che restino centinaia di dispositivi esposti anche a fine 2026, replicando lo schema già visto con altre vulnerabilità KEV rimaste irrisolte per lungo tempo.
  2. Altri gruppi ransomware oltre a INC adotteranno lo stesso vettore d’accesso, seguendo il modello già visto con exploit precedenti diventati di dominio pubblico su forum criminali.
  3. SonicWall pubblicherà probabilmente ulteriori dettagli forensi o strumenti di rilevamento gratuiti, sulla scia di quanto fatto da altri fornitori dopo incidenti zero-day di portata simile.
  4. Le autorità di regolamentazione europee, inclusa l’Agenzia per la Cybersicurezza Nazionale in Italia, useranno probabilmente questo caso come esempio concreto nelle prossime comunicazioni su NIS2 relative alla gestione delle patch critiche.
  5. È probabile che emergano nuove varianti del malware KNUCKLEBALL o Sou5, adattate per eludere le firme di rilevamento pubblicate dai fornitori di sicurezza dopo la disclosure.

Domande frequenti

Cos’è SonicWall SMA1000 e a cosa serve?

È una famiglia di appliance per l’accesso remoto sicuro (modelli SMA 6210, SMA 7210 e SMA 8200v) che sostituisce le VPN tradizionali con un portale centralizzato di autenticazione, usato da aziende ed enti pubblici per collegare dipendenti e collaboratori da remoto.

Cosa sono CVE-2026-15409 e CVE-2026-15410?

Sono due vulnerabilità zero-day divulgate da SonicWall il 14 luglio 2026. La prima è una SSRF non autenticata con CVSS 10.0, la seconda è un’iniezione di codice post-autenticazione con CVSS 7.2 che permette l’escalation a privilegi root.

La mia appliance SMA1000 è vulnerabile?

Lo è se esegue una delle versioni firmware elencate nella tabella di questo articolo e non è ancora stata aggiornata alla release 12.4.3-03453 o 12.5.0-02835, entrambe rilasciate il 14 luglio 2026.

Esiste un workaround se non posso aggiornare subito?

No. SonicWall non ha pubblicato mitigazioni temporanee per queste due vulnerabilità. L’unica protezione efficace è l’aggiornamento immediato del firmware.

Perché il furto dei semi TOTP è più pericoloso del furto di una password?

Perché con il seed segreto un aggressore può generare autonomamente codici di autenticazione validi in qualsiasi momento futuro, aggirando di fatto la protezione offerta dal secondo fattore anche dopo la modifica delle password.

Chi è INC Ransomware?

È un gruppo ransomware attivo tramite un modello di affiliazione, individuato da Resecurity come responsabile dello sfruttamento successivo delle vulnerabilità SonicWall per ottenere accesso iniziale a reti aziendali con finalità estorsive.

Come faccio a sapere se sono già stato compromesso?

Verifica i log per connessioni websocket anomale sulla porta 443, operazioni non pianificate sul flusso remove_hotfix, sessioni amministrative da IP inconsueti e modifiche non tracciate alla configurazione della console di gestione.

Quali aziende italiane rischiano di essere colpite?

Le organizzazioni di medie e grandi dimensioni che usano SMA1000 per l’accesso remoto, inclusi fornitori di servizi gestiti che offrono connettività VPN a clienti terzi, con un effetto di propagazione che può coinvolgere anche aziende che non usano direttamente il prodotto.