Synology DSM, vulnerabilità SA-26:19: SQL injection e bypass di rsync, come aggiornare

Il 10 novembre Synology ha pubblicato il bollettino Synology-SA-26:19, classificato come critico, che riguarda DSM 7.2.1, 7.2.2, 7.3 e 7.4. A differenza di altri bollettini, qui non c’è un pacchetto opzionale da disinstallare: il problema è nel sistema operativo del NAS, quindi sono coinvolti di fatto tutti i dispositivi che non hanno ancora installato l’ultima build della propria versione.

Le vulnerabilità sono due. La più grave, CVE-2026-76954 (CVSS 9.8), è una SQL injection nell’Auth API di DSM, cioè proprio nella parte che gestisce l’accesso: secondo Synology permette a un attaccante remoto di leggere o scrivere file arbitrari e di causare un denial of service. La seconda, CVE-2026-85101 (CVSS 8.6), è un bypass dell’autenticazione nel servizio rsync, con cui si possono leggere alcuni file, scriverne di arbitrari e causare un denial of service limitato. Per nessuna delle due serve un account sul NAS.

Al momento non risultano attacchi in corso né exploit pubblici, e Synology non indica nessuna mitigazione alternativa: l’unica correzione è l’aggiornamento. Dopo quello che abbiamo visto poche settimane fa con il ransomware C3RB3R sui NAS Synology, che colpisce proprio i dispositivi rimasti indietro con le patch, io non aspetterei.

Chi è coinvolto

Sono vulnerabili i NAS con una build precedente a queste, che sono quelle indicate da Synology come corrette:

• DSM 7.4: 7.4.1-90080-1 o successiva
• DSM 7.3: 7.3.2-86009-5 o successiva
• DSM 7.2.2: 7.2.2-72806-10 o successiva
• DSM 7.2.1: 7.2.1-69057-13 o successiva

Notate che per DSM 7.4 la correzione arriva con la 7.4.1: chi è ancora sulla 7.4 iniziale deve fare il salto di versione minore, non basta un aggiornamento cumulativo. Il rischio maggiore è per chi ha l’interfaccia di DSM raggiungibile da Internet (porte 5000/5001 inoltrate sul router, o porte personalizzate) e per chi espone il servizio rsync per ricevere backup da sedi remote o da altri NAS.

Prima di iniziare

• Verificate che l’ultimo backup del NAS (Hyper Backup, Snapshot Replication o quello che usate) sia andato a buon fine e sia recente. Un aggiornamento di DSM raramente dà problemi, ma “raramente” non è “mai”.
• Esportate la configurazione da Pannello di controllo → Aggiornamento e ripristino → Backup della configurazione: occupa pochi kilobyte e in caso di guai fa risparmiare ore.
• Pianificate il riavvio: il NAS resterà irraggiungibile per qualche minuto, quindi avvisate chi lavora sulle cartelle condivise e fermate eventuali VM su storage iSCSI o NFS.

Verificare la versione installata

Da interfaccia aprite Pannello di controllo → Centro informazioni → Generale e leggete la riga della versione DSM. Se gestite molti NAS e avete SSH abilitato, è più rapido da riga di comando:

ssh [email protected]
cat /etc.defaults/VERSION

Confrontate i valori productversion, buildnumber e smallfixnumber con l’elenco sopra: per esempio una 7.2.2 con build 72806 e smallfix inferiore a 10 è ancora vulnerabile.

Aggiornare DSM

1. Aprite Pannello di controllo → Aggiornamento e ripristino → Aggiornamento DSM e premete Verifica aggiornamenti.
2. Se compare la build corretta, scaricatela e installatela. Se il NAS non la propone ancora (la distribuzione è spesso graduale), scaricate il file .pat dal Centro download di Synology per il vostro modello esatto e usate Aggiornamento manuale DSM.
3. Dopo il riavvio ricontrollate la versione come visto sopra e verificate che volumi, cartelle condivise e attività di backup siano regolari.
4. Già che ci siete, nelle impostazioni di aggiornamento attivate almeno l’installazione automatica degli aggiornamenti importanti: è la stessa raccomandazione che Synology ha ripetuto dopo gli attacchi di ottobre.

Attenzione: se siete ancora su DSM 7.2.1 o 7.2.2 l’aggiornamento nello stesso ramo chiude il buco, ma non rimandate troppo il passaggio a una versione più recente. Ho spiegato come affrontarlo in NAS Synology su DSM 7.2: come passare a DSM 7.3 o 7.4. Non fate però il salto di versione maggiore di corsa per risolvere questa emergenza: prima la build corretta del vostro ramo, poi la migrazione con calma.

Ridurre l’esposizione di DSM e rsync

Synology non propone mitigazioni, ma queste sono misure che io applico comunque su tutti i NAS che gestisco, e che limitano i danni anche per le prossime vulnerabilità:

• Niente DSM esposto su Internet. Togliete dal router i port forwarding verso le porte di amministrazione e usate una VPN per l’accesso da remoto. Lo sconsiglio sempre, a maggior ragione con una falla nell’Auth API.
• rsync solo se serve. In Pannello di controllo → Servizi file → rsync controllate se il servizio è attivo. Se non ricevete backup da altri dispositivi, disattivatelo. Se vi serve, limitatelo agli indirizzi IP dei NAS o server di origine.
• Firewall di DSM. In Pannello di controllo → Sicurezza → Firewall create regole che permettano l’interfaccia di gestione e rsync solo dalle subnet interne o dalla VPN, con un’ultima regola che nega tutto il resto.

Per verificare cosa risponde davvero, provate le porte da un PC della rete e, per l’esposizione esterna, da una connessione diversa da quella aziendale (per esempio l’hotspot del telefono) verso l’IP pubblico. Da PowerShell:

Test-NetConnection 192.168.1.10 -Port 873
Test-NetConnection 203.0.113.10 -Port 5001

Il valore TcpTestSucceeded : True sull’IP pubblico indica che quella porta è raggiungibile da Internet. La 873 è la porta predefinita del servizio rsync: se l’avete cambiata, provate quella configurata.

Se il problema persiste

Se l’aggiornamento manuale rifiuta il file, quasi sempre il .pat è di un altro modello o di un ramo diverso: riscaricatelo controllando il nome esatto del NAS. Se il NAS non riparte o i volumi risultano degradati dopo il riavvio, non insistete con altri riavvii: aprite un ticket a Synology allegando i log, e nel frattempo tenete a portata di mano il backup della configurazione esportato prima.

Se invece notate file rinominati, cartelle condivise svuotate o accessi sospetti nel Centro log su un NAS che è rimasto esposto, scollegatelo dalla rete prima di fare qualsiasi altra cosa e trattatelo come un incidente: aggiornare un sistema già compromesso non basta.

Vi è capitato di trovare NAS con DSM pubblicato su Internet o rsync aperto senza motivo? Raccontate nei commenti come li avete messi in sicurezza: possono essere utili ad altri.