rsync 3.5.2 schließt DoS-Lücke CVE-2026-119741 und Filterfehler im Daemon
rsync 3.5.2 ist seit dem 3. November 2026 verfügbar. Es schließt CVE-2026-119741, über die Angreifer ohne Anmeldung die CPU öffentlicher rsync-Daemons auslasten können, und behebt einen Fehler, bei dem Filterregeln eines Daemon-Moduls mit --files-from umgangen wurden.
Die rsync-Entwickler haben Version 3.5.2 veröffentlicht. Auf GitHub ist das Release seit dem 3. November 2026 abrufbar, die Änderungsliste datiert es auf den 4. November. Das Update schließt die Denial-of-Service-Lücke CVE-2026-119741 und behebt eine Reihe weiterer Fehler, darunter einen, bei dem ein rsync-Daemon Dateien ausliefern konnte, die ein Filter eigentlich ausschließen sollte.
Am stärksten betroffen sind Betreiber eines rsync-Daemons mit öffentlich lesbaren Modulen, etwa Spiegelserver. Wer rsync nur als Client über SSH für Backups und Migrationen nutzt, hat bei der CVE ein geringeres Risiko und kann das Update mit den normalen Paketupdates der Distribution einspielen.
Was ist passiert?
CVE-2026-119741 steckt laut dem CVE-Eintrag von VulnCheck in der Funktion hash_search() des Delta-Transfers. Ein bösartiger Empfänger kann schwache Prüfsummen schicken, die mit aufeinanderfolgenden Fenstern der Quelldatei kollidieren. Der Sender berechnet dann an jeder dieser Stellen eine starke Prüfsumme. Über mehrere gleichzeitige Verbindungen lässt sich so die CPU des sendenden Systems auslasten. Laut CVE-Eintrag können das Angreifer ohne Anmeldung, wenn sie von einem öffentlichen Daemon-Modul lesen dürfen. Version 3.5.2 begrenzt diesen Aufwand.
Daneben nennt die Änderungsliste mehrere Korrekturen mit Sicherheitsbezug, aber ohne eigene CVE-Nummer. Bei einem Abruf mit --files-from aus einem Unterverzeichnis eines Daemon-Moduls las rsync die Dateien aus dem Wurzelverzeichnis des Moduls. Dabei konnte eine gleichnamige Datei übertragen werden, die der Filter des Moduls ausschließt, mit --remove-source-files konnte sie sogar gelöscht werden. Behoben sind außerdem ein Stapelüberlauf im Daemon-Empfänger, ein Schreibzugriff außerhalb des Puffers bei Prüfsummen der Länge null und ein Fehler bei Passwortdateien mit leerer erster Zeile. Steuerzeichen in Dateinamen und Meldungen gibt rsync nun maskiert aus.
Wer ist betroffen?
Von CVE-2026-119741 sind laut CVE-Eintrag alle rsync-Versionen bis einschließlich 3.5.1 betroffen. Ohne Anmeldung ausnutzbar ist die DoS-Lücke über einen rsync-Daemon, dessen Module Unbekannte lesen dürfen. Der Fehler mit --files-from betrifft Daemon-Module mit Filterregeln. Wann die einzelnen Distributionen Pakete mit den Korrekturen ausliefern, geht aus den Quellen nicht hervor.
Wie kritisch ist das?
VulnCheck bewertet CVE-2026-119741 mit CVSS 8.7 nach Version 4.0 und 7.5 nach Version 3.1. Die Lücke beeinträchtigt nur die Verfügbarkeit, Daten lassen sich darüber weder lesen noch ändern. Hinweise auf Ausnutzung gibt es laut der Einstufung der US-Behörde CISA im CVE-Eintrag bisher nicht. Für Spiegelserver und offene Backup-Ziele ist eine einfache Möglichkeit zur CPU-Erschöpfung trotzdem ärgerlich, weil sie andere Dienste auf demselben Host mitzieht. Der Filterfehler wiegt aus Sicht der Datensicherheit schwerer, ist aber an eine bestimmte Konstellation gebunden.
Was sollten Admins jetzt tun?
- Inventar: mit
rsync --versiondie installierte Version prüfen und klären, wo ein rsync-Daemon läuft, etwa über/etc/rsyncd.confoder einen lauschenden Port 873. - Patchstand: auf 3.5.2 oder einen Distributionsstand mit den Korrekturen aktualisieren und den Daemon neu starten.
- Erreichbarkeit: Port 873 nur für bekannte Gegenstellen öffnen und Module ohne öffentlichen Zweck auf Authentifizierung umstellen.
- Filter prüfen: Module, die per Filter Dateien ausblenden, auf Abrufe mit
--files-fromin den Logs durchsehen. - Skripte: Backup-Jobs mit Passwortdateien kontrollieren, deren erste Zeile leer ist. Bisher nahm rsync in diesem Fall eine spätere Zeile als Passwort.
Einordnung für Unternehmen
Für die meisten kleinen Firmen ist rsync ein Werkzeug in Backup-Skripten über SSH, dort ist 3.5.2 ein normales Wartungsupdate. Wer dagegen einen rsync-Daemon betreibt, etwa als Sicherungsziel auf einem NAS, sollte die Version zeitnah anheben und prüfen, ob die Module wirklich offen erreichbar sein müssen. Neu sind außerdem die Optionen --nice für die Prozesspriorität und --delay-symlinks.
Passende Anleitungen auf S-EDV
- rsync über SSH: Daten synchronisieren und migrieren
- UGREEN NAS zu NAS mit rsync sichern: ohne Rechte-Falle
