SonicWall SMA1000: CVE-2026-15409 concatena SSRF e root

Il 14 luglio 2026 SonicWall ha detto ai clienti SMA1000 di aggiornare due vulnerabilità già sfruttate — non teoriche, non proof-of-concept, ma usate in incidenti reali che i suoi stessi responder avevano gestito. Nel giro di poche ore CISA ha aggiunto sia CVE-2026-15409 sia CVE-2026-15410 al catalogo Known Exploited Vulnerabilities, fissando al 17 luglio la scadenza federale di remediation ai sensi della BOD 26-04. È un orologio da tre giorni su un'appliance di secure access che, per progettazione, sta sul perimetro e termina le sessioni VPN di tutta l'azienda. Se gestite un SMA1000 e leggete queste righe dopo il 17, date per scontato di essere in ritardo.

La parte interessante non è che l'ennesima edge appliance abbia avuto un bug critico. È come i due bug si combinano — e perché la lettura istintiva dell'advisory ("uno dei due richiede un admin autenticato, quindi siamo quasi al sicuro") è esattamente la conclusione sbagliata.

La catena SonicWall SMA1000: due bug, un confine che crolla

Presi singolarmente, i due CVE sembrano gestibili. Presi come la catena documentata dal team MDR di Rapid7, sono un percorso pre-auth fino a root.

• CVE-2026-15409 — una Server-Side Request Forgery nell'interfaccia Work Place di SMA1000, CVSS 10.0, raggiungibile da un attaccante remoto e non autenticato. Il bug vive nel proxy websocket /wsproxy sulla porta 443. Gli si passa un parametro host che punta all'appliance stessa — localhost, 0.0.0.0, ::ffff:127.0.0.1 — e il proxy si collega diligentemente a servizi interni mai pensati per affacciarsi su internet, incluso il processo di management Erlang in ascolto su localhost:1050.
• CVE-2026-15410 — una code injection nella Management Console, CVSS 7.2, nominalmente subordinata a un amministratore autenticato. La falla è un path traversal nel workflow remove_hotfix sulla porta 8188: si costruisce un parametro hotfix come ../../../../var/tmp/privesc e la console esegue comandi controllati dall'attaccante come root.

La catena è tutta la storia. La SSRF dà all'attaccante non autenticato un punto d'appoggio dentro il confine di fiducia dell'appliance — un'origine di richiesta che il piano di management tratta come locale e privilegiata. Da lì la code injection "solo autenticata" non è più protetta da nulla che l'attaccante debba rubare prima. Il perimetro che faceva sembrare CVE-2026-15410 un 7.2 evapora.

Passo	CVE	Componente	Porta	Cosa ottiene l'attaccante
1	CVE-2026-15409 (SSRF)	Work Place /wsproxy	443	Origine richiesta non autenticata dentro la box; raggiunge localhost:1050
2	CVE-2026-15410 (code injection)	Management Console remove_hotfix	8188	Esecuzione comandi arbitraria come root
3	Post-exploit	Store di sessione + config TOTP	—	Credenziali, cookie di sessione, seed MFA

Perché la "RCE autenticata" non è mai stata una mitigazione

I vendor descrivono i bug post-autenticazione come fanno perché, in isolamento, quella descrizione è accurata. Il problema nasce quando si scambia quella descrizione per un controllo. L'autenticazione è un confine solo se l'attaccante non può fabbricarsi il contesto autenticato in un altro modo. Sull'SMA1000, un secondo bug non autenticato fabbrica esattamente quel contesto.

"Abbiamo patchato CVE-2026-15409 la mattina stessa. La SSRF è chiusa. Siamo a posto?" "Avete patchato anche la 15410?" "Quella richiede un login admin — l'abbiamo messa in coda con priorità più bassa." "La SSRF era il login admin. Ed è girata per giorni prima che patchaste. Tirate fuori i log."

È lo schema dietro quasi ogni breach serio di edge appliance degli ultimi tre anni: il CVE da titolo è un singolo bug, ma l'intrusione è una catena, e i difensori dimensionano la risposta sul bug invece che sulla catena. I gateway SSL-VPN e di secure access sono la superficie di accesso iniziale più bersagliata proprio perché una concessione dell'appliance dà accesso autenticato a tutto ciò che le sta dietro. Gli apparati SMA1000 di SonicWall sono già comparsi in passato nella reportistica sull'accesso iniziale ransomware; questo è quello stesso schema, ora automatizzato in un exploit a due stadi.

Cosa hanno fatto gli attaccanti dopo root — la parte che la patch non risolve

Il motivo per cui questo advisory non è un "patcha e vai avanti" è ciò che Rapid7 ha osservato dopo la shell di root. Gli operatori sono andati dritti al materiale di credenziali di cui un concentratore SSL-VPN è purtroppo ricco:

• Database di sessione attivi esfiltrati (richieste a /tmp/temp.db*), consegnando agli attaccanti sessioni vive che sopravvivono a un reset password.
• Configurazioni dei seed TOTP MFA rubate — l'attaccante può ora generare codici di secondo fattore validi per gli account di cui ha preso i seed. Ruotare solo le password non chiude questo buco: i seed vanno rigenerati.
• Credenziali di utenti e amministratori raccolte in massa.

Poi l'appliance stessa è stata riutilizzata. Rapid7 descrive gli SMA1000 compromessi che diventano backdoor "senza VPN": autenticazioni Active Directory dirette verso i domain controller, originate dall'IP interno dell'appliance stessa nel contesto del suo service account LDAP integrato, con hostname non aziendali — una macchina attaccante osservata si presentava come kali. In termini ATT&CK è T1190 (exploit public-facing application) → T1548 (abuse elevation control) → T1078 (valid accounts) e T1556/T1111 (modify authentication / intercept MFA) per i seed rubati.

L'implicazione è netta: su un dispositivo dove l'attaccante ha raggiunto root e prelevato gli store di sessione e TOTP, aggiornare il firmware sfratta la vulnerabilità ma non l'intruso. Si deve dare per perso il materiale di credenziali.

Remediation

Trattate qualunque SMA1000 esposto su internet con una build vulnerabile come compromesso finché la forensics non dice il contrario. L'ordine qui sotto conta.

1. Sono impattato?

La serie SMA1000 — SMA6210, SMA7210, SMA8200v e CMS — è impattata su queste build (da SonicWall SNWLID-2026-0008):

• 12.4.3-03245, 12.4.3-03387, 12.4.3-03434
• 12.5.0-02283, 12.5.0-02624, 12.5.0-02800

Verificate il firmware in esecuzione nella management console o dal banner dell'appliance. La serie SMA100, più bassa di gamma, e i firewall Gen7 sono una linea di prodotto diversa e non sono coperti da questo notice — non fatevi rassicurare se gestite un SMA1000.

2. Patch — versioni corrette esatte

Aggiornate a, testuale dal notice del vendor:

• 12.4.3-03453 e superiori, oppure
• 12.5.0-02835 e superiori

Non esiste un workaround di configurazione che chiuda la SSRF non autenticata lasciando l'appliance in servizio. La patch è il controllo.

3. Non riuscite a patchare subito? — controlli compensativi

Se davvero non potete applicare l'aggiornamento immediatamente, la guida onesta della BOD 26-04 vale: mettete l'appliance offline. Come hardening provvisorio mentre preparate l'upgrade:

• Limitate l'esposizione del piano di management (la porta 8188 e i servizi di management interni non devono mai essere raggiungibili da internet).
• Mettete davanti all'interfaccia Work Place una regola WAF che rifiuti le richieste /wsproxy i cui parametri host/target risolvono al loopback (localhost, 0.0.0.0, 127.0.0.1, ::ffff:127.0.0.1) — smorza la primitiva SSRF ma non sostituisce la patch.
• Restringete gli IP sorgente ai range noti dei client VPN se la vostra popolazione utenti lo consente.

4. Cacciate la compromissione — segnali e IOC

Raccogliete i log dell'appliance prima di re-immaginarla. Cercate:

• extraweb_access.log — abuso del proxy websocket: voci con GET + wsproxy + =-3389 + stato HTTP 101; parametri host 0.0.0.0, localhost o ::ffff:127.0.0.1.
• ctrl-service.log — invocazioni remove_hotfix con sequenze di path traversal (../../../../../../tmp/) e qualunque evento di "hotfix removal" non avviato da voi.
• /var/lib/unit/conf.json — route sospette iniettate per /__api__/login, /__api__/logout o /wsproxy.
• Artefatti di furto sessione — letture di /tmp/temp.db*.
• Rete — traffico in ingresso dai range IP che Rapid7 attribuisce all'ASN 206092 (F.N.S Holdings Limited): 45.131.194.0/24, 45.146.54.0/24, 63.135.161.0/24, 173.239.211.0/24, e gli host 193.37.32.179, 193.37.32.214, 216.73.163.151, 216.73.163.158.
• A valle — autenticazioni AD verso i domain controller originate dall'IP interno dell'appliance, soprattutto sotto il service account LDAP o da hostname non aziendali (kali e simili). È l'indizio del movimento laterale, e sta nei log dei vostri DC, non nell'appliance.

Mappate i riscontri su T1190, T1548, T1078, T1556/T1111.

5. Eradicate + verificate

Poiché l'attaccante aveva root e accesso agli store di credenziali, la guida di SonicWall è re-immaginare o ridistribuire ogni appliance su cui si sospetta compromissione — un upgrade firmware sopra una compromissione viva non è eradicazione. Dopo una ricostruzione pulita su build corretta:

• Resettate tutte le credenziali che hanno mai autenticato attraverso o sono state memorizzate sull'appliance — admin locali, service account e in particolare il service account LDAP integrato.
• Rigenerate i seed TOTP/MFA per gli utenti impattati. Seed rubati significano secondo fattore compromesso finché non riemesso; non saltate questo passo perché avete cambiato le password.
• Invalidate tutte le sessioni attive — il database di sessione esfiltrato contiene token che sopravvivono ai reset password.
• Verificate la pulizia dopo la patch, non prima: confermate il firmware corretto, confermate che non ci siano route abusive in conf.json e confermate che gli IOC sopra siano assenti in una cattura fresca.

Dove si inserisce Zero Hunt

Tutto quanto sopra è una catena, non un CVE — ed è il punto che la maggior parte degli scanner manca. Uno strumento di version-match vi dice che la box gira 12.5.0-02800 e segnala due CVE. Non vi dice che la SSRF non autenticata raggiunge la management console, che quindi l'injection "autenticata" è in pratica pre-auth, né che l'esito realistico è root più uno store TOTP rubato. Il divario tra "due CVE presenti" e "ecco il percorso funzionante da internet al vostro domain controller" è dove vive il rischio reale.

Lo swarm a 10 agenti di Zero Hunt è costruito per chiudere quel divario. Su un'appliance come questa, gli agenti Recon e Web mappano le superfici Work Place e di management esposte, il motore generativo dell'agente Exploit scrive una primitiva SSRF su misura contro il comportamento reale di /wsproxy invece di rigiocare un PoC pubblico, e gli agenti Pivot e Post-Exploit portano quell'origine dentro l'injection della console e fino agli store di credenziali e TOTP — provando l'intera catena, o provando che non arriva. Ogni skill usata dallo swarm è backtestata nell'AI Gym contro corpora di CVE black-box prima di toccare un asset di produzione, e ogni finding è firmato ECDSA affinché la prova — questo input, questa risposta, root qui — regga in un audit o in una richiesta assicurativa. Poiché l'appliance è sul perimetro e le campagne change-triggered partono entro un'ora dalla comparsa di un nuovo asset, la catena viene esercitata secondo i vostri tempi, non quelli dell'attaccante.

E per la parte che la patch non può annullare — la raccolta di credenziali e il pivot verso AD senza VPN — il modello di traffico on-appliance di Zero Hunt osserva il filo mentre accade: le quattro inference head segnalano le autenticazioni anomale a origine interna verso i vostri domain controller, le letture degli store di sessione e lo staging in uscita che gli upgrade firmware non vedono mai, girando localmente sulla GPU dell'appliance invece di aspettare il digest SIEM di domani. La vulnerabilità aveva una patch il 14 luglio. L'intrusione dietro di essa va cacciata — ed è un lavoro diverso.