Debian Rsync CVE: Upgrading to 3.5.0 in Your Homelab

On 13 August 2026, rsync 3.5.0 was released with fixes for 33 security issues, the result of a focused audit of rsync’s path handling and daemon protocol plus daemon-protocol fuzzing and external reports (including Trail of Bits). CVE IDs were assigned by VulnCheck. Debian then shipped it to Debian 13 (trixie) as a security update, DSA-6527-1, as version 3.5.0+ds1-0+deb13u1. Debian normally backports individual fixes; replacing the upstream version in a stable release is unusual and shows how much changed.

What was fixed

Most of the issues are symlink and path races: a local user who controls part of a path plants or swaps in a symlink, and a more privileged rsync follows it. Examples from the rsync NEWS file:

• CVE-2026-53802 (high): rsync followed attacker-planted symlinks in operator-supplied input files: filter merge files, --files-from, --include-from/--exclude-from, and password or secrets files.
• CVE-2026-53803 (high): symlinked output paths (--log-file, --write-batch, daemon motd and lock files) could redirect writes, for example appending to authorized_keys.
• CVE-2026-53784 (high): with use chroot = no, a daemon module could serve files from outside the module via a symlinked parent directory.
• Several medium-severity races in the receiver and sender, including ACL/xattr application and --remove-source-files.

Most of these matter when another user can write into the paths rsync touches: shared machines, daemon modules others upload to, backups of directories other users own. A single-user homelab is less exposed, but backup servers often run rsync as root over other machines’ data, which is exactly the privileged side these bugs target.

Behaviour changes that can affect backups

From the 3.5.0 NEWS:

• A non-daemon receiver only follows a symlinked destination directory if the symlink is owned by root or the running user. A destination symlinked by another user is refused. --insecure-links restores the old behaviour.
• In-tree symlinked directories are now resolved by a single race-free walk on every platform, so -K, -L, -k and -R behave the same everywhere.
• support/rrsync in a restricted subdirectory forces --no-D and denies --copy-unsafe-links.
• A daemon with proxy protocol = true but no proxy protocol hosts now rejects all connections.

rsync 3.5.1 (21 September) fixed regressions from 3.5.0. Explicit sender paths through symlinked parents work again. --files-from paths are treated as operator-supplied paths rather than paths beneath the transfer root. Reading batch data from a FIFO or process substitution works again. If a backup script broke after the update, check whether your distribution has a 3.5.1-based package yet.

Update

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade rsync
rsync --version | head -1

Check the fixed version for your release on the Debian tracker, e.g. https://security-tracker.debian.org/tracker/CVE-2026-53802. On other distributions, look for their advisory for the same CVEs.

Update every machine that runs rsync in your backup chain, client and server. The fixes protect the side that runs the fixed version.

Check all hosts

for node in nas pve1 pve2 backup; do
  printf '%s: ' "$node"
  ssh -o BatchMode=yes "$node" 'rsync --version | head -n1'
done

While you’re at it: don’t expose the daemon

The rsync daemon protocol (rsyncd, port 873) is unencrypted. Don’t expose it to the internet or untrusted networks. Run rsync over SSH, or keep rsyncd on a trusted network behind a firewall. For restricted backup accounts over SSH, rsync ships rrsync, which locks an SSH key to one directory.

After updating, run your backup jobs once by hand and read the output, so a changed behaviour shows up now rather than as a silent failure in a month.

What’s Next

• Debian 13.5 Trixie: What Homelab Admins Should Know
• Linux Homelab Security Hardening: Complete Checklist (2026)
• Ubuntu Rust Coreutils: Fixing Homelab Automation Scripts
• Mitigating 400+ Linux Kernel CVEs in Your Homelab