In questo articolo Indice dei contenuti 3 sezioni
Con il rilascio di rsync 3.5.0 arriva uno degli aggiornamenti più pesanti sul fronte sicurezza mai visti nella storia del progetto: 33 vulnerabilità corrette in un colpo solo, di cui una critica, 17 classificate come alte e 15 di rischio medio. Non è un rilascio ordinario, insomma. Le falle sono emerse da un audit mirato che ha passato al setaccio la gestione dei percorsi e il protocollo del demone, affiancato da una campagna di fuzzing, e la nuova versione porta con sé anche una serie di misure di hardening. Per chiunque tenga in piedi rsync come servizio di rete, per backup o per mirror, aggiornare è una priorità e non un consiglio.
Cosa correggono le 33 vulnerabilità di rsync 3.5.0
La maggior parte delle nuove CVE ruota attorno a race condition sui symlink, traversal di percorsi, scritture fuori dalla directory prevista, bypass dei controlli di accesso, injection di argomenti, corruzione della memoria e denial of service. Ogni correzione è stata accompagnata da un test di regressione, così che il comportamento corretto venga verificato in automatico anche in futuro. Tra le falle più significative compaiono CVE-2026-53802 e CVE-2026-53803, insieme ad altre legate a regole di filtro, directory implicite e operazioni di rename o hard link.
La più severa del gruppo è CVE-2026-53791, l’unica classificata come critica, e tocca il parametro “proxy protocol = true”. Prima di questa versione un client poteva spedire un header PROXY anche senza passare da un proxy attendibile, falsificando di fatto l’indirizzo sorgente e aggirando eventuali controlli basati su IP. Adesso l’indirizzo inoltrato viene accettato solo se la connessione arriva da un peer configurato come proxy fidato. In assenza di proxy protocol hosts, l’impostazione blocca l’accesso invece di lasciar passare.
Percorsi ancorati ai file descriptor, addio ai controlli su stringa
Buona parte dei problemi nasce da condizioni TOCTOU, ovvero time of check to time of use: il programma controlla che un percorso sia dentro una directory autorizzata, ma nel frattempo un attaccante modifica uno dei componenti di quel percorso. Un classico, difficile da chiudere con i controlli testuali.
La risposta degli sviluppatori è stata abbandonare, dove possibile, le verifiche basate su stringhe per passare a risoluzioni ancorate a file descriptor. Su Linux 5.6 e superiori rsync sfrutta openat2() con RESOLVEBENEATH e RESOLVENO_MAGICLINKS, impedendo al kernel di uscire dall’albero consentito tramite “..”, symlink assoluti o collegamenti speciali. Il risultato è che una race condition ha molte meno possibilità di dirottare un’operazione verso un inode esterno alla directory autorizzata, cosa che pesa parecchio sui server dove rsync gira con privilegi elevati.
Lo stesso ragionamento è stato esteso a rrsync, lo script wrapper usato per limitare le operazioni di un account SSH. Qui CVE-2026-53783 consentiva di scavalcare le restrizioni sulla directory autorizzata sfruttando proprio una finestra TOCTOU. La 3.5.0 “pinnia” l’inode verificato e usa il file descriptor per ancorare il percorso che viene poi passato a rsync.
Protocollo, denial of service e verifica TLS
L’audit ha tirato fuori anche diversi problemi nel protocollo vero e proprio. CVE-2026-70461, CVE-2026-70458 e CVE-2026-70456 sono scritture oltre i limiti di memoria nell’heap che si verificano durante la gestione di regole di filtro, hard link o argomenti ricevuti dal peer. Per contenere il rischio sono stati introdotti limiti più stretti sui valori controllati dal peer: l’opzione compress threads, per esempio, ora è limitata a otto per una connessione al demone, così che parametri del tutto legittimi non si trasformino in uno strumento per bruciare risorse.
Ci sono poi le falle di denial of service che non passano dalla corruzione della memoria. CVE-2026-70464 permetteva a un peer non autenticato di tenere occupato un processo del demone inviando con lentezza calcolata i pezzi del protocollo iniziale, mentre CVE-2026-70453 riguardava un comportamento quadratico nella ricerca degli hash. Ritocchi anche per rsync ssl: CVE-2026-70454 sistema una debolezza nella verifica TLS quando si usa stunnel, che adesso pretende la verifica del certificato e la corrispondenza del nome host, a meno di scegliere esplicitamente una modalità non sicura.
