rsync 3.5.0 was released on August 13, and the project’s own NEWS file describes it as an “extraordinary release” because of the sheer number of security issues it closes: 33 of them, in a single version.

That number sounds alarming until you understand where it came from. This was not 33 independent discoveries trickling in over years. It was the output of a focused audit of rsync’s path handling, daemon protocol, and related code, plus fuzzing of the daemon protocol. When you point that kind of attention at a codebase that has been quietly doing the same job since the nineties, you find things in clusters.

The proxy protocol flaw

The one to check first is CVE-2026-53791, which affects rsync daemons configured with proxy protocol = true.

On an affected daemon, a client could supply its own PROXY header. Since the whole point of the proxy protocol is to tell the daemon the real client address behind a load balancer, a client that can write that header can claim to be coming from anywhere. Host-based access controls built on hosts allow and hosts deny stop meaning much at that point.

This only matters if you actually enabled proxy protocol. Check before you panic:

grep -r "proxy protocol" /etc/rsyncd.conf /etc/rsyncd.d/ 2>/dev/null

If that returns nothing, you were never exposed to this particular issue. You still want the other 32 fixes.

Symlinks, again

A large share of the remaining fixes deal with symlink handling and path confinement. Several carry High severity, and the pattern is consistent: an attacker-influenced symlink or crafted path could redirect an rsync operation outside the directory it was supposed to stay inside.

This is the oldest trap in file synchronization. rsync’s job is to reproduce a directory tree faithfully, symlinks included, and the boundary between “faithfully reproduce this link” and “follow this link somewhere it should not go” is exactly where the bugs live. Options like --copy-links, --keep-dirlinks, and --munge-links exist precisely because that boundary needs to be configurable, and configurable boundaries are boundaries that can be got wrong.

If you run an rsync daemon that accepts uploads from hosts you do not fully control, this is your upgrade.

Memory safety in the daemon protocol

Daemon-protocol fuzzing turned up several memory-safety issues, including heap out-of-bounds writes in filter processing, argument parsing, and hard-link handling.

Note the common thread: all three are reachable through the daemon protocol. If you use rsync purely over SSH, which is how most people use it, your exposure is much narrower, because the remote rsync runs as your user after SSH has already authenticated you. The daemon protocol is the part that talks to strangers.

# Over SSH: the remote side runs as you, after authentication
rsync -avz -e ssh /srv/data/ user@backup:/srv/data/

# Daemon mode: rsyncd is listening, and speaks to whoever connects
rsync -avz /srv/data/ rsync://backup.example.com/data/

Our rsync command builder generates the SSH form by default, and the scp, sftp, and rsync comparison covers when each transport is the right choice.

What to do

Upgrade. The maintainers recommend it for all users, and given that the fixes came from a systematic audit rather than active exploitation reports, there is no reason to wait for a proof of concept to show up.

# Check your version
rsync --version | head -1

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

# Fedora
sudo dnf upgrade rsync

# Arch
sudo pacman -Syu rsync

If you run rsync daemons, restart them after upgrading. If you run rsync out of cron for automated backups, the next run picks up the new binary automatically, but it is worth confirming the version rather than assuming.

The uncomfortable takeaway

Thirty-three issues in one audit is not a sign that rsync is badly written. It is a sign that nobody had audited these specific code paths with modern tooling and modern expectations until now.

There is a long tail of infrastructure software in exactly this position: correct enough to have run for decades, written before the threat model included “hostile input from the internet as a routine condition,” and never systematically fuzzed. rsync just got its turn. Other tools on your servers have not had theirs yet.