rsync 3.5 ships 33 security fixes at once, including a critical proxy protocol flaw
On August 13, 2026 the rsync team released version 3.5, closing 33 CVEs including a critical flaw (CVE-2026-53791) that let a client spoof its source address through the proxy protocol. If your backups run as root over SSH, this is the update to apply first.
August 13, 2026. Andrew Tridgell announced on the rsync-announce list that rsync 3.5.0 is out — a release the project itself calls “extraordinary”: 33 CVEs fixed in one go, including one critical and a long tail of high-severity flaws. Behind that number sits a reality almost nobody had confronted: the most widely used backup tool on the planet had not been properly audited in years.
If your backup script runs rsync as root over SSH — and most do — this is the fix that goes to the top of your queue this week.
What the audit found
The 33 CVEs did not come from a pile of unrelated external reports. The project says the issues were found through a focused audit of path handling and the daemon protocol, a fuzzing pass against that protocol, and external researcher reports. Three angles of attack, one conclusion: rsync’s attack surface was far larger than its “plumbing” reputation suggested.
The critical flaw, CVE-2026-53791, hits daemons configured with proxy protocol = true. Until now, a client connecting directly to the daemon — rather than through the trusted proxy it expected — could supply its own PROXY header, spoof its source IP address, and as a result bypass host-based access controls. That is the textbook definition of a flaw that turns a filtering policy into decoration.
The remaining fixes split into two families that look a lot alike: symlinks and memory.
Symlinks, the old enemy
Most of the high-severity flaws abuse symbolic link handling. In practice, an attacker could redirect an rsync operation outside its intended directory: arbitrary file read through a symlinked input file, arbitrary file write and privilege escalation through a symlinked output path.
The affected options map onto real-world usage: --relative, --temp-dir, --link-dest, ACL and extended-attribute handling, directory enumeration, and --remove-source-files. rrsync, the restricted SSH wrapper that is supposed to confine clients in the first place, also gets extra protection against directory escapes and unsafe options.
The structural answer is called secure_relative_open(). It is a hardened path-resolution framework that pins directory file descriptors and blocks symlink hops out of the permitted tree. In other words, rather than patching each case one by one, the team closed the entire class.
Memory and the daemon protocol
The audit also surfaced memory-safety issues reachable through the daemon protocol: heap out-of-bounds writes in filter processing, argument parsing, and hard-link handling. Found by fuzzing, these bugs can be triggered remotely with crafted protocol data.
On top of that, a quadratic CPU exhaustion triggered by crafted checksum chains was fixed, and the hosts deny file now behaves defensively: an unresolved deny entry fails closed instead of letting the connection through.
On the client side, a flaw let a malicious peer manipulate the client’s I/O timeout. And for encrypted transfers, rsync-ssl now performs proper certificate verification and hostname binding with stunnel, unless you explicitly opt out — an opt-out nothing justifies in production.
A thirty-year-old tool under the spotlight
This salvo did not come from nowhere. In June 2026, release 3.4.3 had already triggered a public debate over a regression introduced by AI-assisted code — a sign that a tool maintained by a handful of contributors for decades was starting to attract scrutiny its code had never received. The summer audit is the logical follow-up: somebody finally sat down to look at path handling end to end.
The result speaks plainly. A tool everyone treats as a given — closer to a pipe than to software — was hiding 33 flaws, including an entire symlink class. That is exactly the kind of finding that emerges when you audit a critical component before it gets exploited rather than after.
The severity spread tells its own story: a single critical flaw in the proxy path, a long run of high-severity symlink and memory issues, and a tail of hardening fixes that never earned a CVE number but matter in practice — log injection, checksum denial-of-service, certificate verification in rsync-ssl. This is what a mature security pass looks like: not one headline bug, but a systematic sweep of every path a hostile input can take.
What changes for your configuration
The hardened release is not transparent. Two behavior changes deserve attention before you upgrade:
proxy protocolwithout trusted hosts = connection refused. Settingproxy protocol = truewithout declaring the proxy’s trusted hosts now rejects connections instead of accepting them. An existing deployment that relied on the old leniency will find itself closed — on purpose, but you need to know before upgrading.- A non-daemon receiver only follows a symlinked destination directory if that symlink is owned by root or by the user running rsync. One more brake on silent redirection.
Finally, some bonus hardening: control characters in filenames are escaped before being written to logs (against terminal and log injection), a --safe-links bypass is closed, and PROXY headers are length-limited.
To check what you are running and upgrade:
# Version currently installed
rsync --version | head -1
# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade rsyncOn a pinned distribution, the rsync package will stay on 3.4.x: it is the backport that carries the fixes, not the version number on screen.
Are you affected?
Three profiles stand out, with rising levels of risk — and different priorities:
- A root-over-SSH backup script — by far the most common case. You expose no daemon, but the symlink class still applies: a compromised client or a trapped path can write outside the intended directory. Same fix, one notch lower urgency.
- An internal
rsyncddaemon — centralized backups, repository mirrors, fleet synchronization. The protocol’s memory flaws and module escapes hit you directly, because any client on the local network can trigger them. - An exposed
rsyncddaemon withproxy protocol = true— this is the exact profile of CVE-2026-53791, the critical flaw. If this is you, the upgrade does not wait: your access control is compromised.
Three commands tell you where you stand:
# Version in place
rsync --version | head -1
# Is the daemon active on this machine?
systemctl is-active rsyncd 2>/dev/null || echo "no active daemon"
# Is the proxy protocol configured?
grep -E "^\s*proxy protocol" /etc/rsyncd.conf 2>/dev/null || echo "proxy protocol not configured"The third one is the key: if grep returns a proxy protocol = yes (or true) line, you are in the critical profile, and the move to 3.5 belongs on this week’s schedule, not the next maintenance cycle.
Verdict
Priority depends on your profile, but the conclusion is the same for everyone: upgrade.
If you run an exposed rsyncd daemon — especially with proxy protocol = true — CVE-2026-53791 is your problem directly: apply the fix now and re-check your trusted-host list while you are at it.
If your backups run as root over SSH, the symlink class is your main risk: a compromised client can write outside the intended directory. Move to a patched version and, while you wait for your distro package, restrict modules and enable rrsync.
On Debian stable or Ubuntu LTS, do not chase 3.5.0 itself: a fix list this long turns into a long tail of backports on the 3.4.1 and 3.2.7 branches. Watch your distribution’s security advisory, which will arrive before the literal “3.5.0” package.
The real lesson of the week is not technical: rsync is plumbing, a tool nobody thinks of as an attack surface — until somebody sits down and audits it properly. That 33 CVEs fell out of a single pass says a lot about what you find when you actually look.