Rsync 3.5: 33 vulnerabilities in one release — who does this affect on a home server

Home infrastructure
, , , ,
1

rsync 3.5.0: 33 fixed vulnerabilities
rsync 3.5.0: 33 fixed vulnerabilities1280×670 35.5 KB

The date in the NEWS file is August 13, 2026, and the announcement circulated on the evening of the 12th. rsync 3.5.0 release fixes 33 vulnerabilities: this is the result of a targeted audit of path handling and the daemon protocol, not just a routine batch of bug fixes. One hole is marked as CRITICAL, seventeen as HIGH.

The tool that on a home server typically lives in three lines of cron and is forgotten for years suddenly demands attention. Let’s break it down by roles: the risk heavily depends on how exactly rsync is run on your side.

Info:

In thanks to the release — researchers Trail of Bits and Google Cloud, plus independent reporters. The full list of CVEs with descriptions is in the official NEWS on download.samba.org; everything below is taken from there.

Role 1. Simply rsync -a between your own machines over SSH

The most common scenario: laptop → home server, server → external drive. Here both ends are yours, and an attacker would need to get onto one of the machines first.

Risk is moderate, but not zero. Some bugs trigger when the remote side is hostile, not when the client is hostile. For example, CVE-2026-53789 (MEDIUM) — a malicious daemon-sender could extend the scope of --delete on the receiver; CVE-2026-70462 (MEDIUM) — the peer side could inject MSG_IO_TIMEOUT and thereby disable your own I/O timeout. That is, it suffices to synchronize once with a чужим зеркалом.

Separately: CVE-2026-70454 (MEDIUM) — rsync-ssl would establish a TLS connection without authentication. If you used the rsync-ssl wrapper, consider that there was no protection there.

Role 2. rsyncd (daemon on 873/tcp) is up

Here things are more serious — the majority of the 33 findings relate specifically to the daemon. The key:

CVE Level Summary
CVE-2026-53791 CRITICAL with proxy protocol = true the client could spoof the source address
CVE-2026-70452 HIGH hosts deny “opened” if the hostname could not be resolved
CVE-2026-70463 HIGH auth users ignored documented comma-separated list parsing
CVE-2026-70456 HIGH writes beyond the heap in read_args()
CVE-2026-70461 HIGH single-byte write beyond in add_implied_include()
CVE-2026-70455 HIGH the client could request an arbitrary number of Zstandard threads (--compress-threads)
CVE-2026-70464 HIGH unauthenticated peer hung a child process forever
CVE-2026-53784 HIGH escape from root of module when use chroot = no

The top three lines are not overflows but rather access control bypasses: both hosts deny, auth users, and source address spoofing mean that your ACLs might not work as written in the config.

Security:

Public rsyncd without authentication in 2026 is basically an anachronism. If it’s exposed to the outside, update should be combined with moving over WireGuard or SSH transport. hosts allow in rsyncd.conf after CVE-2026-70452 no longer looks like a reliable perimeter.

Role 3. rrsync in authorized_keys — recipient of backups

Classic setup: client key is configured with command="rrsync -wo /srv/backup" so it can only push backups and nothing else. CVE-2026-53783 (HIGH) — escape from a restricted directory, precisely the boundary for which rsync is installed.

In 3.5.0 the behavior was tightened: support/rrsync in a restricted subdirectory now forcibly enables --no-D and forbids --copy-unsafe-links.

What changed in behavior (could break your scripts)

  • The receiver outside daemon mode follows a symlink to the destination directory only if the link belongs to root or the current user; a link created by another uid is now rejected.
  • proxy protocol = true without proxy protocol hosts now rejects all connections (fail-closed) — previously it would pass.
  • The nested Unix socket, passed under --specials, on platforms without race-condition-safe socket creation in a subdirectory is skipped with a warning, rather than breaking the entire transfer.
Warning:

The first item is the most likely source of “suddenly broke.” If your backup destination is a symlink created by the service user, and rsync is launched by another user, the transfer will silently stop working. Check the output, not just the return code.

How to upgrade

Success:
  • rsync --version — on both ends. Upgrade both client and server: some vulnerabilities are exploited from the “other side.”
  • In stable distributions the package will still be around: Debian/Ubuntu typically backport patches to an older version, so rely on the package changelog rather than the 3.5.0 number.
  • In container backup stacks (rsync inside the image) rebuild the image — the base layer will not update by itself.
  • If rsyncd exposes to the Internet and you cannot upgrade right away: close 873/tcp with a firewall until you upgrade. It’s cheaper than dealing with the fallout.

The topic of how to actually set up backups on a home server was covered separately — a roadmap from the first container to fault tolerance.

Sources

Question:

Who still has rsyncd exposed to the outside — and why didn’t you move to SSH transport? Real-world reasons are welcome, not “couldn’t be bothered”: there are scenarios where the daemon is truly more convenient.