Auf einen Blick
- Was: rsync 3.5.0 schließt 33 Sicherheitslücken, eine davon kritisch.
- Wer betroffen: Alle rsync-Nutzer, besonders wer den rsync-Daemon betreibt.
- Schweregrad: Kritisch bei
proxy protocol = true, sonst hoch bis mittel. - Was tun: Auf 3.5.0 updaten, Daemon-Konfiguration prüfen, Dienst nicht öffentlich exponieren.
Es ist das Werkzeug, das in fast jedem Homelab läuft — meist unbemerkt, meist nachts: rsync. Der Klassiker kopiert Dateien zwischen Rechnern, spiegelt NAS-Ordner, füttert Backup-Skripte und steckt in unzähligen Fertig-Lösungen. Und genau dieses Werkzeug hat jetzt das größte Sicherheitsupdate seiner Geschichte bekommen.
Am 13. August 2026 hat rsync-Erfinder Andrew Tridgell die Version 3.5.0 veröffentlicht. Im Gepäck: 33 geschlossene Sicherheitslücken. Nicht 3. Nicht 13. Dreiunddreißig.
SO kam die Lawine zustande
Die Zahl klingt dramatisch, die Entstehung ist es weniger — und das ist die gute Nachricht. Die Lücken stammen aus einem gezielten Audit: Das Projekt hat die Pfad-Behandlung und das Daemon-Protokoll systematisch auseinandergenommen, dazu kam ein Fuzzing-Durchlauf auf das Daemon-Protokoll und Meldungen externer Forscher.
Anders gesagt: Hier hat niemand 33 aktive Angriffe entdeckt. Hier hat ein Team einmal richtig aufgeräumt und alles gemeldet, was es gefunden hat. Genau so soll Sicherheitsarbeit aussehen.
DIESE Lücke ist die gefährlichste
Ganz oben auf der Liste steht CVE-2026-53791, eingestuft als kritisch. Sie betrifft rsync-Daemons, bei denen die Option proxy protocol = true gesetzt ist. Das ist keine Standard-Einstellung — wer sie aber nutzt, weil der Daemon hinter einem Load-Balancer oder Reverse-Proxy hängt, sollte sofort handeln.
Darunter reihen sich mehrere hoch eingestufte Probleme:
- CVE-2026-53802 — über verlinkte Eingabedateien (Symlinks) ließen sich fremde Dateien auslesen oder die Übertragung manipulieren.
- CVE-2026-70464 — ein Gegenüber ohne Anmeldung konnte die Begrüßung des Daemons abschließen und die Verbindung danach ewig offen halten. Klassischer Blockade-Angriff.
- CVE-2026-53792 — ein manipulierter Empfänger schickte eine Prüfsummen-Kopfzeile mit Blocklänge null und trieb die Rechnung auf der Senderseite ins Negative. Blocklänge null wird jetzt abgelehnt.
- CVE-2026-53794 —
--max-alloc=0hebelte die Obergrenze pro Speicheranforderung aus und ließ sich sogar an einen ungepatchten Daemon weiterreichen.
Nebenbei ist ein Bug gefallen, der seit 2021 im Bugtracker schlummerte: Der Blockade-Fehler in hash_search hat mit CVE-2026-70453 endlich eine saubere Lösung bekommen.
BIST DU betroffen? So findest du es heraus
Wichtig für die Einordnung — und das geht in vielen Schlagzeilen unter: Die gefährlichsten Lücken betreffen den rsync-Daemon, also den Modus, in dem rsync als Dienst auf Port 873 lauscht und Module anbietet. Wer rsync ausschließlich über SSH benutzt (rsync -a quelle/ user@host:/ziel/), sitzt deutlich entspannter, sollte aber trotzdem updaten.
Prüfe in drei Schritten:
- Version anzeigen:
rsync --version— steht dort etwas unterhalb von 3.5.0, ist ein Update fällig. - Läuft ein Daemon?
systemctl status rsyncbeziehungsweisess -tlnp | grep 873. Antwortet da etwas, gehörst du zur Risikogruppe. - Konfiguration checken: In
/etc/rsyncd.confnachproxy protocolsuchen. Steht dorttrue, ist das dein dringendster Punkt.
SO updatest du sauber
Die meisten Distributionen ziehen 3.5.0 über die normalen Paketquellen nach — bei Debian und Ubuntu also sudo apt update && sudo apt upgrade, bei Fedora sudo dnf upgrade rsync. Wer nicht warten will oder eine ältere LTS-Basis fährt, findet die Quellen auf den Samba-Servern.
Zwei Dinge, die viele vergessen:
- Container und NAS zählen mit. Dein Backup-Container, dein Synology- oder Unraid-Share, dein Router mit rsync-Paket — überall steckt eine eigene rsync-Version. Ein Update auf dem Hauptrechner rettet die anderen nicht.
- Daemon nicht ins Internet stellen. Der beste Schutz gegen Daemon-Lücken ist ein Daemon, den niemand von außen erreicht. rsync über SSH oder über ein VPN ist fast immer die bessere Wahl.
WARUM das mehr ist als ein Routine-Update
rsync ist ein Stück Infrastruktur, das kaum jemand aktiv pflegt, weil es einfach funktioniert. Genau deshalb sind solche Audits so wertvoll — und genau deshalb rutschen die Updates so oft durch. Wenn dein Backup-Skript seit drei Jahren unverändert läuft, ist heute ein guter Tag, einmal nachzusehen.
Und die zweite Lehre: Ein Backup, das über eine kaputte Übertragung läuft, ist kein Backup. Es ist ein Gefühl.
Häufige Fragen
Muss ich updaten, wenn ich rsync nur über SSH nutze?
Ja, aber weniger dringend. Die kritischen Lücken sitzen im Daemon-Protokoll. Über SSH bist du deutlich besser geschützt, weil vor rsync bereits die SSH-Anmeldung greift. Ein Update ist trotzdem sinnvoll, weil auch Sender- und Empfängerseite Fixes bekommen haben.
Woher weiß ich, ob bei mir der rsync-Daemon läuft?
Prüfe mit ss -tlnp | grep 873, ob etwas auf Port 873 lauscht, und mit systemctl status rsync, ob der Dienst aktiv ist. Antwortet keiner der beiden Befehle, nutzt du rsync vermutlich nur als Kommandozeilen-Werkzeug.
Was bedeutet proxy protocol = true?
Diese Option lässt den rsync-Daemon eine vorgeschaltete Proxy-Zeile auswerten, um die echte Client-Adresse zu erfahren. Sie kommt zum Einsatz, wenn ein Load-Balancer oder Reverse-Proxy davor sitzt. Genau dieser Auswertungspfad enthielt die kritische Lücke.
Gibt es Hinweise auf aktive Angriffe?
Zum Zeitpunkt der Veröffentlichung liegen keine Berichte über aktive Ausnutzung vor. Die Lücken stammen aus einem geplanten Audit samt Fuzzing, nicht aus einem Vorfall. Das ist aber kein Grund, das Update aufzuschieben — öffentliche CVE-Details senken die Hürde für Angreifer.
Was ist mit alten NAS-Geräten, die kein Update bekommen?
Dort hilft nur Abschottung: den rsync-Dienst deaktivieren, wenn er nicht gebraucht wird, ihn niemals ins offene Internet stellen und Zugriffe über VPN oder ein separates VLAN kanalisieren.