EN
en direct

rsync 3.5 publie 33 correctifs de sécurité d’un coup

Le 13 août 2026, l’équipe rsync livre la version 3.5, qui referme 33 CVE dont une faille critique (CVE-2026-53791) permettant d’usurper une adresse source via le proxy protocol. Si vos sauvegardes tournent en root sur SSH, c’est la mise à jour à appliquer en priorité.

Un mur de tiroirs métalliques anthracite dans une salle d’archives sombre, un seul tiroir entrouvert laissant filtrer un mince filet de lumière ambre.

13 août 2026. Andrew Tridgell annonce sur la liste rsync-announce la sortie de rsync 3.5.0, une version que le projet qualifie lui-même d’« extraordinaire » : 33 CVE corrigées d’un coup, dont une critique et de nombreuses haute sévérité. Derrière ce chiffre, une réalité que presque personne n’avait regardée en face — l’outil de sauvegarde le plus répandu de la planète n’avait pas été audité en profondeur depuis des années.

Si votre script de sauvegarde lance rsync en root sur SSH — et c’est le cas de la plupart —, voici le correctif qui doit passer en tête de votre file cette semaine.

Ce que l’audit a trouvé

Les 33 CVE ne sortent pas d’une série de rapports externes isolés. Le projet précise que les failles viennent d’un audit ciblé du traitement des chemins et du protocole du démon, d’un fuzzing mené contre ce protocole, et de rapports de chercheurs externes. Trois angles d’attaque, une même conclusion : la surface de rsync était bien plus large que ce que son statut de « plomberie » laissait croire.

La faille critique, CVE-2026-53791, touche les démons configurés avec proxy protocol = true. Jusqu’ici, un client qui se connectait directement au démon — au lieu de passer par le proxy de confiance attendu — pouvait fournir son propre en-tête PROXY, usurper son adresse IP source et, par ricochet, contourner les contrôles d’accès fondés sur l’hôte. C’est la définition exacte d’une faille qui transforme une politique de filtrage en simple décoration.

Le reste des correctifs se répartit en deux familles qui se ressemblent beaucoup : les symlinks et la mémoire.

La majorité des failles hautes gravité exploite la gestion des liens symboliques. Concrètement, un attaquant pouvait rediriger une opération rsync hors de son répertoire prévu : lecture de fichier arbitraire via un fichier d’entrée qui est un symlink, écriture arbitraire et escalade de privilèges via un chemin de sortie symlinké.

Les options concernées dessinent la carte des usages réels : --relative, --temp-dir, --link-dest, la gestion des ACL et des attributs étendus, l’énumération de répertoires, et --remove-source-files. rrsync, le wrapper SSH restreint censé justement confiner les clients, reçoit lui aussi des protections supplémentaires contre les échappées de répertoire et les options dangereuses.

La réponse structurelle s’appelle secure_relative_open(). C’est un cadre de résolution de chemins durci qui épingle les descripteurs de fichier des répertoires et bloque les sauts de symlink hors de l’arborescence autorisée. Autrement dit : plutôt que de corriger chaque cas un par un, l’équipe a fermé la classe entière de vulnérabilités.

La mémoire et le protocole du démon

L’audit a aussi révélé des problèmes de sûreté mémoire atteignables à travers le protocole du démon : des écritures hors limites dans le tas lors du traitement des filtres, de l’analyse des arguments et de la gestion des liens durs. Ces bugs, découverts par fuzzing, peuvent être déclenchés à distance avec des données de protocole spécialement conçues.

S’y ajoute un épuisement CPU quadratique provoqué par des chaînes de checksums fabriquées, et un comportement durci du fichier hosts deny : une entrée deny non résolue fait désormais échouer la connexion en fermé au lieu de la laisser passer.

Côté client, une faille permettait à un pair malveillant de manipuler le timeout d’E/S du client. Et pour les connexions chiffrées, rsync-ssl effectue désormais une vérification de certificat et une liaison au nom d’hôte avec stunnel, sauf désactivation explicite — un opt-out que rien ne justifie en production.

Un outil de trente ans sous les projecteurs

Cette salve ne tombe pas du ciel. En juin 2026, la version 3.4.3 de rsync avait déjà déclenché un débat public sur la régression introduite par du code assisté par IA — un signe que l’outil, maintenu par une poignée de contributeurs depuis des décennies, commençait à attirer une attention que son code n’avait jamais reçue. L’audit de l’été en est la suite logique : quelqu’un s’est enfin assis pour regarder le traitement des chemins de bout en bout.

Le résultat le dit sans détour. Un outil que tout le monde considère comme acquis — plus proche d’un tuyau que d’un logiciel — cachait 33 failles, dont une classe symlink entière. C’est exactement le genre de découverte qui arrive quand on audite un composant critique avant qu’il ne soit exploité, plutôt qu’après.

Ce qui change pour votre configuration

La version durcie n’est pas transparente. Deux changements de comportement méritent votre attention avant la mise à jour :

  • proxy protocol sans hôtes de confiance = connexion refusée. Configurer proxy protocol = true sans déclarer les hôtes de confiance du proxy rejette désormais les connexions au lieu de les accepter. Un déploiement existant qui comptait sur l’ancien laxisme se retrouvera fermé — c’est voulu, mais il faut le savoir.
  • Le récepteur non-démon ne suit un répertoire de destination symlinké que si ce symlink appartient à root ou à l’utilisateur qui exécute rsync. Un frein supplémentaire aux redirections silencieuses.

Enfin, des durcissements « bonus » : les caractères de contrôle dans les noms de fichiers sont échappés avant écriture dans les logs (contre l’injection de terminal et de log), un contournement de --safe-links est refermé, et les en-têtes PROXY sont limités en longueur.

Pour vérifier ce que vous exécutez et mettre à jour :

bash
# Version actuellement installée
rsync --version | head -1

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade rsync

Sur une distribution à version figée, le paquet rsync restera en 3.4.x : c’est le backport qui apporte les correctifs, pas le numéro de version affiché.

Êtes-vous concerné ?

Trois profils se dégagent, avec des niveaux de risque croissants — et des priorités différentes :

  • Le script de sauvegarde en root sur SSH — le cas de loin le plus répandu. Vous n’exposez aucun démon, mais la classe symlink vous concerne : un client compromis ou un chemin piégé peut écrire hors du répertoire attendu. Le correctif est le même, l’urgence un cran plus basse.
  • Le démon rsyncd interne — sauvegardes centralisées, miroirs de dépôts, synchronisation de parcs. Les failles mémoire du protocole et les échappées de module vous concernent directement, car un client du réseau local peut les déclencher.
  • Le démon rsyncd exposé avec proxy protocol = true — c’est le profil exact de CVE-2026-53791, la faille critique. Si c’est votre cas, la mise à jour n’attend pas : c’est une compromission de votre contrôle d’accès.

Pour savoir où vous en êtes, trois commandes suffisent :

bash
# Version en place
rsync --version | head -1

# Le démon est-il actif sur cette machine ?
systemctl is-active rsyncd 2>/dev/null || echo "pas de démon actif"

# Le proxy protocol est-il configuré ?
grep -E "^\s*proxy protocol" /etc/rsyncd.conf 2>/dev/null || echo "proxy protocol non configuré"

Le point clé est le troisième : si le grep remonte une ligne proxy protocol = yes (ou true), vous êtes dans le profil critique, et la migration vers 3.5 doit être planifiée pour cette semaine, pas pour le prochain cycle de maintenance.

Verdict

La priorité dépend de votre profil, mais la conclusion est identique pour tous : mettez à jour.

Si vous exploitez un démon rsyncd exposé — surtout avec proxy protocol = true —, CVE-2026-53791 vous concerne directement : appliquez le correctif sans attendre et revérifiez votre liste d’hôtes de confiance au passage.

Si vos sauvegardes tournent en root sur SSH, la classe symlink est votre risque principal : un client compromis peut écrire hors du répertoire prévu. Passez sur une version corrigée et, en attendant le paquet de votre distribution, restreignez les modules et activez rrsync.

Sur Debian stable ou Ubuntu LTS, ne courez pas après la 3.5.0 elle-même : un correctif aussi long se traduit par une longue traîne de backports sur les branches 3.4.1 et 3.2.7. Surveillez l’avis de sécurité de votre distribution, qui arrivera avant le paquet « 3.5.0 » proprement dit.

Le vrai enseignement de la semaine n’est pas technique : rsync est de la plomberie, un outil que personne ne considère comme une surface d’attaque — jusqu’à ce que quelqu’un s’assoie et l’audite correctement. Que 33 CVE sortent d’un seul passage en dit long sur ce qu’on trouve quand on regarde vraiment.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Clop exfiltre les données d’ingénierie de Shell, GE et Philips via PTC Windchill

Le 14 août 2026, Shell confirme enquêter après que Clop a revendiqué le vol de 89 Go de données, dont des plans d’ingénierie, via la faille CVE-2026-12569 de PTC Windchill et FlexPLM. Les équipes PLM exposées doivent vérifier leurs instances et traquer les webshells JSP déposés dans le répertoire de connexion.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer