SonicWall SMA1000 sotto attacco: zero-day in catena e RCE su Switchvox

🛡️ Executive Summary

• SonicWall conferma lo sfruttamento attivo di CVE-2026-83548 e CVE-2026-83549 contro SMA1000, con una catena che può arrivare all’esecuzione di codice.
• Switchvox CVE-2026-9586 viene sfruttata senza credenziali per eseguire SQL arbitrario e distribuire reverse shell sui sistemi VoIP esposti.
• Forescout usa Claude per adattare un exploit pre-auth RCE tra PLC WAGO, ma servono oltre otto ore, forte supervisione umana e 535 dollari di API.

Tre sviluppi concentrati nelle stesse ore mostrano come stia cambiando la velocità con cui vulnerabilità e exploit diventano strumenti operativi. SonicWall ha confermato lo sfruttamento attivo di due nuove falle sulle appliance SMA1000, con una vulnerabilità pre-authentication da CVSS 10.0 e una seconda RCE post-authentication. Contemporaneamente CVE-2026-9586 in Sangoma Switchvox viene utilizzata contro sistemi reali per ottenere reverse shell senza credenziali. Sul fronte della ricerca offensiva, Forescout Vedere Labs ha invece dimostrato che Claude può adattare un exploit RCE esistente da un PLC WAGO a un altro modello, pur richiedendo ancora intervento umano continuo, più di otto ore di lavoro e un costo API superiore a 500 dollari.

SonicWall conferma due nuove vulnerabilità SMA1000 sfruttate negli attacchi

Il rischio più immediato riguarda le appliance SonicWall Secure Mobile Access 1000, già bersaglio di numerose campagne nel corso del 2026. Nel nuovo product notice SNWLID-2026-0016 pubblicato il 1° settembre, il produttore descrive CVE-2026-83548, una Server-Side Request Forgery pre-authentication classificata CVSS 10.0, e CVE-2026-83549, una vulnerabilità RCE post-authentication valutata CVSS 7.8. SonicWall specifica soprattutto che entrambe risultano attivamente sfruttate in the wild. Sono interessati i modelli SMA 6210, 7210 e 8200v, compresi gli hypervisor virtuali, sui rami firmware 12.4.3 e 12.5.0 indicati nell’advisory. Le versioni corrette sono 12.4.3-03526 e 12.5.0-02952. La prima falla consente a un aggressore remoto non autenticato di abusare dell’interfaccia WorkPlace come forward proxy verso destinazioni che non dovrebbero essere direttamente raggiungibili; la seconda permette invece a un soggetto già dotato dei privilegi necessari di arrivare all’esecuzione di codice sul sistema. SonicWall non pubblica ancora i dettagli completi della catena utilizzata dagli attaccanti, ma raccomanda una risposta che va ben oltre il semplice patching: se vengono trovati indicatori di compromissione, le appliance fisiche devono essere re-imaged, quelle virtuali devono essere ridistribuite, tutte le password utente e amministrative devono essere cambiate e i token TOTP devono essere azzerati. L’urgenza nasce anche dai precedenti. Le SMA1000 erano già finite sotto attacco durante l’estate attraverso CVE-2026-15409 e CVE-2026-15410, due zero-day utilizzate per ottenere accesso root e successivamente inserite anche nelle campagne ransomware. La catena sfruttata da INC ransomware contro SonicWall SMA1000 aveva portato all’installazione di componenti come ROOTRUN, KNUCKLEBALL, Suo5 e ORANGETAIL, dimostrando perché un’appliance VPN compromessa debba essere considerata potenzialmente persistente anche dopo l’aggiornamento. Le due nuove CVE sono distinte da quelle precedenti, e SonicWall precisa espressamente che il nuovo advisory non riguarda altri prodotti del proprio catalogo. Il pattern però resta identico: un apparato collocato sul perimetro aziendale, progettato per mediare accessi remoti e raggiungere risorse interne, diventa un obiettivo privilegiato proprio perché può offrire agli attaccanti visibilità e accessi che sfuggono ai normali controlli endpoint.

Leggi anche: SonicWall SMA1000 entra nelle campagne ransomware dopo lo sfruttamento delle prime zero-day

Switchvox viene attaccato con una SQL injection che arriva alla reverse shell

Il secondo caso riguarda Sangoma Switchvox SMB Edition, piattaforma VoIP utilizzata nelle infrastrutture aziendali. CVE-2026-9586, classificata CVSS 9.3, è una SQL injection pre-authentication nell’endpoint /pa. Il problema nasce dal modo in cui il parametro PhoneIP, contenuto in richieste XML che iniziano con PolycomIPPhone, viene concatenato direttamente nelle query PostgreSQL senza parametrizzazione sufficiente. Un aggressore remoto può quindi eseguire statement SQL arbitrari contro il database backend senza possedere credenziali. Le conseguenze superano la semplice lettura dei dati: i ricercatori hanno dimostrato la possibilità di modificare utenti, elevare privilegi fino all’amministrazione Switchvox e arrivare a esecuzione di codice sul server. Sangoma aveva distribuito la correzione con Switchvox 8.4.0.2 il 14 luglio 2026, ma le evidenze operative indicano ora che i sistemi rimasti vulnerabili vengono effettivamente attaccati.

La fonte originaria dello sfruttamento in the wild è Horizon3.ai, che aveva segnalato a Sangoma un gruppo di dodici vulnerabilità già ad aprile. Il report tecnico aggiornato da Horizon3.ai indica tentativi validi di exploit osservati a partire dal 30 agosto contro i propri honeypot. L’attività porta alla distribuzione di reverse shell e successivamente all’esecuzione di comandi codificati Base64 per enumerare i processi in esecuzione. I ricercatori stimano circa 4.000 istanze Switchvox esposte a Internet, in larga parte negli Stati Uniti, e ritengono probabile che una quota significativa sia già stata scansionata o colpita. Sugli apparati dove SSH è disponibile, l’attività SQL injection può lasciare tracce nel file /var/log/switchvox/db-quirks.log. Horizon3.ai associa inoltre agli attacchi l’indirizzo IP 176.65.148[.]184, già segnalato per scansioni, brute force e attività di exploitation.

La stessa vulnerabilità era stata scoperta indipendentemente da Security Risk Advisors Labs, che ne aveva notificato i dettagli a maggio. I ricercatori SRA sono riusciti non soltanto a ottenere esecuzione di codice, ma anche a estrarre la chiave utilizzata per firmare i cookie, aprendo la possibilità di forgiare materiale di autenticazione per altri utenti. Il punto più critico è quindi la combinazione tra accesso anonimo, controllo del database e capacità di trasformare PostgreSQL in un percorso verso il sistema operativo. Una piattaforma telefonica compromessa può inoltre contenere configurazioni, account, rubriche, integrazioni e credenziali che ne aumentano significativamente il valore per un attaccante.

Claude porta una RCE da un PLC WAGO a un altro ma con forte supervisione umana

Il terzo sviluppo non riguarda uno sfruttamento criminale osservato, ma una ricerca che modifica il calcolo del rischio per le vulnerabilità industriali più vecchie. Forescout Research – Vedere Labs ha utilizzato Claude per adattare un exploit RCE già funzionante contro un PLC WAGO 750-852 a un differente modello WAGO 750-831. Il bersaglio era CVE-2021-31886, buffer overflow pre-authentication nel server FTP Nucleus raggiungibile attraverso la porta TCP 21. La vulnerabilità consente di arrivare all’esecuzione di shellcode ARM senza autenticazione. Nel resoconto originale dell’esperimento, Forescout insiste però su un punto che impedisce di trasformare il test in una dimostrazione di autonomia offensiva completa: il modello ha avuto bisogno di supervisione significativa, correzione di false piste, informazioni ottenute manualmente dal disassembly e continui interventi dei ricercatori.

L’esperimento è iniziato con Claude Sonnet 4.6 ed è successivamente passato a Claude Opus 4.6 quando i primi tentativi di RCE si sono bloccati. Il problema tecnico era particolarmente concreto: nel WAGO 750-831 l’elaborazione FTP azzerava 256 byte all’interno del buffer controllato dall’attaccante, distruggendo il payload prima della sua esecuzione. Claude ha adattato la sequenza utilizzata contro il precedente dispositivo, passando da una combinazione USER e QUIT a USER e CWD e omettendo il terminatore CRLF in modo da mantenere disponibile il buffer abbastanza a lungo da far partire lo shellcode. Una volta raggiunta l’esecuzione, il modello è passato da shellcode NOP a due payload funzionali in circa 12 minuti: il primo generava richieste ICMP verso una macchina controllata dai ricercatori, il secondo inviava un pacchetto UDP contenente la stringa PWNED. Il risultato dimostra quindi una vera capacità di adattamento dell’exploit a un hardware differente, ma non una compromissione end-to-end totalmente autonoma.

L’esperimento costa 535 dollari e termina anche con un PLC definitivamente briccato

Il dato più utile per comprendere lo stato reale delle capacità AI è il costo operativo. La fase finale necessaria per ottenere la RCE ha richiesto 8 ore e 32 minuti e 535,74 dollari di utilizzo API per un solo exploit contro un solo target. Gli stessi ricercatori osservano che un esperto umano avrebbe potuto probabilmente adattare l’exploit in meno tempo e spendendo meno. Il test diventa però interessante quando si guarda alla traiettoria tecnologica: il problema non è che l’AI abbia già sostituito un exploit developer specializzato, ma che una parte del lavoro di reverse engineering e adattamento possa essere progressivamente automatizzata. La precedente compromissione di tre aziende reali durante i test cyber di Anthropic aveva già dimostrato quanto possano diventare imprevedibili agenti dotati di strumenti, rete e obiettivi offensivi, anche quando il contesto originale è una valutazione controllata.

L’esperimento Forescout mostra però anche il limite opposto. Nel tentativo successivo di trasformare la RCE in un vero impianto command-and-control, Claude ha scritto dati in una regione di memoria mappata sulla flash del PLC e ha briccato permanentemente il dispositivo. In un’infrastruttura OT questo genere di errore assume un significato completamente diverso rispetto al crash di un’applicazione tradizionale: un agente autorizzato a manipolare un sistema fisico può produrre indisponibilità o danni anche senza avere intenzioni malevole. Il pericolo immediato evidenziato dai ricercatori non è quindi un modello che decide autonomamente di attaccare una fabbrica, ma un agente cyber a cui è stato affidato un compito legittimo e che compie l’azione sbagliata su hardware industriale reale.

Continua con:

• Gunra e gli attacchi OT contro PLC, inverter e infrastrutture industriali
• Akira entra attraverso SonicWall VPN e spegne EDR e Defender con Safe Mode

AI e zero-day stanno comprimendo il tempo tra vulnerabilità e attacco operativo

I tre casi non devono essere messi sullo stesso piano. SonicWall SMA1000 e Switchvox sono vulnerabilità sfruttate attivamente contro sistemi reali, quindi richiedono patching e incident response immediati. Il test WAGO è invece una ricerca controllata su un problema noto dal 2021 e dimostra soprattutto come possa cambiare il costo futuro dello sviluppo di exploit su sistemi embedded. La relazione tra i tre sviluppi sta nella riduzione progressiva del tempo e delle competenze necessarie per trasformare una vulnerabilità in un accesso operativo. Per le organizzazioni che utilizzano SonicWall SMA1000, il nuovo hotfix deve essere considerato urgente e la presenza di indicatori di compromissione deve portare a re-imaging, rotazione delle password e reset TOTP, non soltanto a un aggiornamento firmware. Per Switchvox, qualsiasi installazione precedente alla 8.4.0.2 esposta a Internet dovrebbe essere considerata ad alta priorità, con controllo dei log e ricerca di reverse shell o comandi anomali. Negli ambienti OT, invece, la lezione è più strategica: vulnerabilità vecchie e considerate difficili da sfruttare potrebbero non restare difficili per sempre. Il punto critico del 2026 è quindi il cambiamento della finestra difensiva. La disponibilità di modelli capaci di assistere nel reverse engineering non cancella ancora la necessità di competenze specialistiche, ma può rendere più rapido il lavoro di chi quelle competenze già possiede. Quando questa accelerazione incontra migliaia di appliance VPN, PBX e PLC esposti su Internet, la distanza tra advisory, exploit e compromissione reale diventa sempre più corta.