Andrew Tridgell, who wrote rsync and has maintained it for three decades, does not use the word "extraordinary" lightly. It is the first word of the release notes for rsync 3.5.0, which landed on August 13 and closes 33 separate security issues in one go. For a tool that ships with essentially every Linux distribution and quietly runs the backups of a large slice of the internet, that is a remarkable number to see in a single line.
Tridgell announced it on the oss-security mailing list with characteristic understatement, pointing readers to the project's own release notes for the detail. The detail is where the story is.
The one rated critical
Exactly one of the 33 carries a critical rating, and it only bites a specific configuration. CVE-2026-53791 applies to daemons running with proxy protocol = true, a setting used when rsync sits behind a load balancer that forwards the real client address. In the project's words, a client connecting directly rather than through the trusted proxy "could send a PROXY header to spoof its source address and bypass host-based access control". If your allowlist is the thing standing between the internet and your rsync daemon, that allowlist was decorative. The fix is that a forwarded address is now honoured only when it comes from a configured trusted-proxy peer.
Check that setting before you do anything else. The other one to grep for is use chroot = no, which CVE-2026-53784 turns into a module-root escape: a plain directory change followed a planted symlink and served files from outside the module.
Bugs that reach in from the wire
The part that should get defenders' attention is a cluster the project separated out deliberately. A fuzzing pass against the daemon protocol, with findings reported by Greg Kroah-Hartman, turned up memory corruption that a peer can trigger across the network. The release notes are blunt about why these were split from the crash-only findings: "Each is a WRITE reachable from the wire."
- CVE-2026-70461, a one-byte heap out-of-bounds write reached through a peer-supplied filter rule whose trailing backslash was not counted when sizing the copy.
- CVE-2026-70456, an out-of-bounds heap write when the peer's argument count lands exactly on the maximum.
- CVE-2026-70458, an out-of-bounds write from a file entry flagged as hard-linked that the receiver accepted even when hard links were not enabled, writing into slots that were never allocated.
Alongside them sit two ways to knock a daemon over. CVE-2026-70464 lets an unauthenticated peer finish the greeting and then stall forever, trickling bytes to hold a connection slot past the module's connection limit, reported independently by Chamal De Silva and by Michal Ruprich of Red Hat QE. CVE-2026-70455 let a client ask for any number of compression threads: 256 requested was measured as 257 threads in a single connection. It is now capped at eight.
The symlink pile
The largest group is a long run of link-following and race-condition bugs, the kind where a local user plants a symlink and waits for a privileged rsync to walk into it. CVE-2026-53802 covers arbitrary file read through symlinked filter files, files-from lists and password files. Its twin CVE-2026-53803 covers arbitrary file write through log files and batch files, and the notes give an example worth pausing on: appending your log output to authorized_keys. CVE-2026-53783 is an escape from rrsync, the restricted wrapper people deploy specifically to confine rsync over SSH, which validated each argument and then handed the same name to rsync, leaving a window in between.
Rather than patch these one at a time, the project built a hardened path resolver, secure_relative_open(), that walks a path component by component and only accepts a symlink component when it is owned by root or by the effective user.
What you should do
Upgrade to 3.5.0. If you are pinned to a distribution package, backport patch sets went to the distros list a week before release and branches exist for 3.4.1 and 3.2.7, so your vendor update is probably close behind. Before you get there, audit any daemon config for proxy protocol and use chroot, since those two settings decide whether you are patching routinely or urgently. One detail deserves emphasis and cuts against panic: the notes state that each advisory carries its own introduced-in range and that many are "much narrower than everything before 3.5.0", so read the ranges rather than assuming every version you run is affected by all 33.
Two things about this release are worth more thought than the CVE count. The first is how the bugs were found: a deliberate audit of path handling, a protocol fuzzing pass, and outside contributions including Filipe Casal of Trail of Bits, who supplied fixes and tests under a program run in collaboration with OpenAI. Machine-assisted bug hunting is now finding real, wire-reachable memory corruption in code that has been stable for decades, the same pattern we saw when AI tooling surfaced the SharePoint chain behind a server takeover. The second is quieter. Tridgell thanks the volunteers who helped write guidelines for "where to draw the line between a security issue and expected behaviour", calling it a surprisingly difficult thing to do. Thirty years in, a tool this widely deployed is still negotiating which of its behaviours count as bugs, and it is fair to wonder what the next audit of the next universally installed utility turns up.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.