Se la tua attività utilizza un firewall SonicWall, oppure affidi l’IT a un managed service provider (MSP) che accede da remoto per mantenere aggiornati e sottoposti a backup i tuoi sistemi, hai due motivi distinti per fare una telefonata questa settimana. Entrambi riguardano vulnerabilità che gli aggressori stanno sfruttando proprio ora, non rischi teorici descritti in un bollettino del fornitore che nessuno legge. Nessuno dei due casi richiede che tu diventi un esperto di sicurezza. Richiede però che tu faccia domande specifiche e pretenda risposte specifiche — date, numeri di versione, conferme — non rassicurazioni.

Ecco cosa sta succedendo in ciascun caso, insieme a una checklist che puoi copiare, incollare e inviare a chiunque gestisca la tua rete.

Problema 1: il tuo firewall SonicWall (CVE-2026-15409 e CVE-2026-15410)

SonicWall ha divulgato e corretto due vulnerabilità il 14 luglio 2026 — ma, secondo la cronologia della stessa azienda, gli aggressori le stavano già sfruttando da circa tre settimane prima della divulgazione pubblica. Questo significa che «ora è corretto» e «ora è sicuro» non sono automaticamente la stessa cosa per un dispositivo che in quel periodo era esposto a Internet.

Il gruppo criminale più frequentemente associato a questa catena di vulnerabilità è INC, un’operazione di ransomware-as-a-service che i ricercatori di Rapid7 descrivono come uno dei gruppi di questo tipo più attivi al mondo in questo momento (anche se non tutti gli attacchi che sfruttano queste falle sono stati collegati con certezza proprio a INC — quasi sicuramente sono coinvolti anche altri aggressori opportunisti). Separatamente, la società di sicurezza Huntress ha segnalato una campagna in rapida evoluzione nella quale 30 clienti SonicWall sono stati compromessi in meno di due giorni. Non si tratta di un rischio a lenta maturazione.

C’è anche una storia rilevante: in precedenza SonicWall aveva divulgato un incidente nel quale un gruppo sponsorizzato da uno Stato aveva sottratto i file di configurazione dei firewall di tutti i clienti SonicWall che utilizzavano la sua funzione di backup sul cloud. Un file di configurazione rubato può contenere credenziali di account locali e impostazioni VPN. Se la configurazione del tuo firewall è mai stata sottoposta a backup sul servizio cloud di SonicWall prima che l’incidente fosse contenuto, correggere le falle attuali non annulla ciò che era già stato esposto — potrebbe essere ancora necessario ruotare le credenziali presenti in quella configurazione.

Checklist da inviare al tuo fornitore IT o MSP:

  • «Quale modello SonicWall e quale versione del firmware stiamo utilizzando attualmente, e questa versione risolve CVE-2026-15409 e CVE-2026-15410?» (Chiedi di confermare sulla base del bollettino ufficiale di SonicWall — non accettare «abbiamo l’ultima versione» senza un numero di versione.)
  • «In quale data abbiamo applicato la patch?» Se è stato dopo il 14 luglio 2026, chiedi di controllare i log delle settimane precedenti per individuare segnali di accesso non autorizzato — accessi imprevisti degli amministratori, nuovi account locali o sessioni SSLVPN provenienti da indirizzi IP sconosciuti.
  • «Il nostro portale SSLVPN o di accesso remoto era esposto a Internet durante quel periodo?» Se sì, chiedi di imporre il reset della password per ogni account che si autentica tramite quel portale, non soltanto di applicare una patch.
  • «La configurazione del nostro firewall è mai stata sottoposta a backup sul servizio cloud di SonicWall e, in caso affermativo, le credenziali presenti in quel file di configurazione sono state ruotate da allora?»
  • «Avete abilitato l’autenticazione a più fattori su tutti gli account di accesso remoto attraverso il firewall?» In caso contrario, chiedi di abilitarla questa settimana.

Problema 2: lo strumento di gestione remota del tuo MSP (CVE-2026-18577 in N-able N-central)

Questo caso è diverso perché non riguarda le tue apparecchiature — è uno strumento che il tuo fornitore IT potrebbe usare per gestire decine o centinaia di aziende clienti, forse anche la tua, da un’unica console centrale. N-able N-central è una di queste piattaforme, e la CISA (l’Agenzia per la sicurezza informatica e delle infrastrutture degli Stati Uniti) ha aggiunto una vulnerabilità presente in essa — CVE-2026-18577, con una gravità valutata 8.2 su 10 — al proprio catalogo delle vulnerabilità note sfruttate, dopo aver confermato lo sfruttamento attivo dal 31 luglio 2026. Secondo quanto riferito, la falla consente a un aggressore di ottenere l’accesso amministrativo completo alla console N-central stessa.

Questo è importante per ciò che un aggressore può fare da lì. Huntress ha riferito che gli attacchi riusciti sono passati dalla console compromessa agli endpoint gestiti tramite essa — il che significa che una violazione dello strumento dell’MSP può trasformarsi in una violazione dei tuoi sistemi senza che l’aggressore ti prenda mai direttamente di mira. Huntress ha inoltre rilevato che gli aggressori creavano tunnel Cloudflare sui sistemi compromessi, una tecnica che offre loro un modo persistente e cifrato per rientrare, che può sembrare traffico web ordinario a un firewall.

Non hai bisogno di sapere se il tuo fornitore specifico utilizza N-central. Devi chiederlo, e devi farlo in modo più ampio, senza limitarti al nome di quel singolo prodotto.

Checklist da inviare al tuo fornitore IT o MSP:

  • «Utilizzate N-able N-central o un altro prodotto N-able per gestire i nostri sistemi?» Se sì: «È stato applicato l’aggiornamento contro CVE-2026-18577 e a quale data?»
  • «Avete verificato l’attività degli account amministrativi e i log degli accessi sulla vostra console di gestione dal 31 luglio 2026, alla ricerca di qualcosa che non riuscite a spiegare?»
  • «Avete controllato specificamente i nostri sistemi alla ricerca di connessioni in uscita inattese — in particolare processi di tunnel Cloudflare (talvolta indicati come “cloudflared”) o domini di tunnel che non avete configurato voi?»
  • «Sono stati inviati ai nostri sistemi nuovi account amministrativi locali, attività pianificate o criteri di gestione remota che non riuscite ad attribuire al vostro team?»
  • «Se non utilizzate N-central, quale strumento di gestione remota utilizzate in alternativa e recentemente sono state aggiunte vulnerabilità relative a quel prodotto al catalogo delle vulnerabilità note sfruttate della CISA?»

Cosa fare con le risposte

Un buon fornitore IT risponderà a queste domande con date e dettagli, spesso entro un giorno, perché dovrebbe già conoscere queste informazioni o riuscire a recuperarle rapidamente dai log. Una risposta vaga — «è tutto sotto controllo», «i nostri sistemi sono sicuri», senza indicare date — è di per sé un’informazione utile: ti dice che questa conversazione deve ripetersi, per iscritto, con una scadenza precisa.

Se gestisci direttamente il tuo SonicWall senza un MSP, la checklist qui sopra si applica comunque direttamente a te — accedi personalmente alla console di gestione, controlla la versione del firmware e consulta la pagina dei bollettini di SonicWall per individuare la versione che risolve entrambe le CVE.

Nessuno di questi difetti richiede di interrompere i rapporti con un fornitore o di licenziare un provider. Richiedono la conferma che la specifica lacuna sia stata colmata e che nulla sia passato attraverso di essa mentre era aperta. Fai le domande, procurati le date e imposta un promemoria sul calendario per chiedere di nuovo la prossima volta che un fornitore comunicherà qualcosa di «sfruttato attivamente». Succederà di nuovo.