rsync DSA-6527-1: Patch 33 CVEs on Debian 13

pajus 2026-10-04 updated 2026-10-08 10 min read

On 2026-09-28 Debian published DSA-6527-1 for rsync. It moves Debian 13 (trixie) to upstream rsync 3.5.0 and fixes 33 CVEs. According to the advisory, the bugs can lead to local privilege escalation, bypass of access restrictions, information disclosure, denial of service or arbitrary code execution. Almost every Debian host has rsync installed, but how urgent the rsync DSA-6527-1 patch is depends on how rsync runs on that host. This post covers how to tell whether a box runs the rsync daemon, accepts rsync over SSH or only uses the client. It then walks through patching, checking that the new binary is the one actually running, testing backup jobs and tightening rsyncd.conf.

What happened: rsync 3.5.0 and DSA-6527-1

Upstream released rsync 3.5.0 on 13 Aug 2026. The release came out of audits of path handling and of the daemon protocol. Debian's advisory, signed by Salvatore Bonaccorso, lists these IDs:

CVE-2026-53783 to CVE-2026-53786 (CVE-2026-53787 is not part of the advisory)
CVE-2026-53788 to CVE-2026-53803
CVE-2026-70452 to CVE-2026-70464

That makes 33 CVEs in total, which matches the count in the upstream NEWS file. The most severe is CVE-2026-53791. When a daemon has proxy protocol = true, a client that connects directly can send its own PROXY header with a forged source address and get past hosts allow/hosts deny. NVD published the CVE on 13 Aug 2026 and shows a secondary (CNA) CVSS 3.1 score of 9.1 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). I did not check the CVSS scores of the other 32 CVEs one by one, so I don't quote them here.

Based on the upstream NEWS, the fixes fall into these groups:

Daemon access control: the PROXY spoofing above. hosts deny failed open when a hostname in the list could not be resolved (CVE-2026-70452). auth users parsing was broken (CVE-2026-70463). The name converter mapped unknown names to uid/gid 0 (CVE-2026-53798).
Memory corruption a peer can trigger: out-of-bounds writes in read_args() (CVE-2026-70456), add_implied_include() (CVE-2026-70461) and hard-link handling (CVE-2026-70458).
Daemon DoS: unauthenticated peers could stall connections indefinitely (CVE-2026-70464), clients could request unlimited Zstandard threads (CVE-2026-70455), and equal weak-checksum chains caused quadratic CPU use (CVE-2026-70453).
Symlink races and path escapes on both sender and receiver. One example is the module-root escape when use chroot = no (CVE-2026-53784).
The rrsync wrapper: a TOCTOU escape from the restricted directory (CVE-2026-53783).
Client side: command injection through unquoted substitutions in RSYNC_CONNECT_PROG, daemon hooks and remote-shell arguments (CVE-2026-53790). rsync-ssl did not verify TLS (CVE-2026-70454).

Who is affected: Debian package status

The versions below come from the Debian security tracker (DSA-6527-1 and the CVE-2026-53791 entry) as of today:

Release	Vulnerable version	Fixed version	Status
Debian 12 bookworm	3.2.7-1+deb12u6 (security: 3.2.7-1+deb12u5)	none yet	vulnerable
Debian 13 trixie	3.4.1+ds1-5+deb13u4	3.5.0+ds1-0+deb13u1	fixed via DSA-6527-1
forky (testing)	—	3.5.0+ds1-1	fixed (current: 3.5.1+ds1-1)
sid	—	3.5.0+ds1-1	fixed (current: 3.5.1+ds1-1)

Bookworm has no fix at the time of writing. If you still run Debian 12, the hardening and exposure steps below are all you can do until a fixed package ships.

Daemon, SSH server or client only: how urgent is the rsync patch?

rsync has three roles, and the exposure is different for each:

Role	What it looks like	Who can reach it	Urgency
Daemon (rsyncd)	`rsync --daemon`, TCP 873, `/etc/rsyncd.conf`	anyone who can reach the port, often without authentication	patch today
Server over SSH	`rsync --server` started by sshd, often forced with `command=` or `rrsync`	holders of a valid SSH key	high, especially for restricted keys
Client only	cron or timer jobs running `rsync src host:dst`	the remote end you connect to	normal; patch at the next window

Check the installed version

dpkg-query -W -f='${Package} ${Version}\n' rsync
apt-cache policy rsync

Anything below 3.5.0+ds1-0+deb13u1 on trixie is vulnerable.

Is the daemon running?

On Debian 13 the package ships /usr/lib/systemd/system/rsync.service. The unit has ConditionPathExists=/etc/rsyncd.conf, so it does nothing until that file exists. Check the unit, the config file and the port:

systemctl is-enabled rsync
systemctl status rsync --no-pager
ls -l /etc/rsyncd.conf
ss -tlnp 'sport = :873'

If ss shows port 873 owned by inetd, xinetd or systemd (socket activation) and not by rsync, the daemon is still in use. It is just started a different way. Also look for daemons started by hand or from scripts:

ps -eo pid,user,lstart,args | grep '[r]sync --daemon'

Is rsync accepting connections over SSH?

Forced commands in authorized_keys are the usual sign of a backup target:

grep -Hn -e 'rsync --server' -e 'rrsync' /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null
grep -rn -e 'ForceCommand' -e 'AuthorizedKeysFile' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Keys without a forced command can run rsync too. Check whether rsync server processes show up while your backup windows are running:

ps -eo pid,user,lstart,args | grep '[r]sync --server'

If none of these checks finds anything, the host probably only uses the rsync client. Patch it anyway. CVE-2026-53790 (command injection) and CVE-2026-70462 (client timeout overflow) both affect the client side, and a compromised backup target can exploit a client that connects to it.

Patch Debian 13 and verify the running binary

Warning: restarting the daemon drops any transfers in progress. Do it outside your backup window.

apt-get update
apt-get install --only-upgrade rsync
dpkg-query -W -f='${Version}\n' rsync
grep ' rsync:' /var/log/dpkg.log | tail -n 3

The daemon forks one child per connection from the long-running parent process. If the parent was started before the upgrade, it keeps running the old, deleted binary. Restart it and confirm:

systemctl restart rsync
pid=$(systemctl show -p MainPID --value rsync)
ls -l /proc/"$pid"/exe

A parent that is still running the old binary looks like this:

/proc/2711/exe -> /usr/bin/rsync (deleted)

After the restart the (deleted) suffix has to be gone. To catch every rsync process that is still on the old binary, including SSH-spawned servers and long client runs:

for p in $(pgrep -x rsync); do ls -l /proc/"$p"/exe; done

Each SSH-mode rsync --server is a new process, so new connections use the patched binary without any restart. Long-running transfers that started before the upgrade keep using the old code until they finish.

Check backup jobs after the upgrade

3.5.0 changes some behaviour on purpose, and that can break existing jobs. These are the items in the upstream NEWS most likely to affect backups:

A non-daemon receiver now follows a symlinked destination directory only if root or the running user owns the symlink. Destinations symlinked by another uid are refused. --insecure-links brings back the old behaviour, but fix the ownership instead.
rrsync in a restricted subdirectory now forces --no-D and refuses --copy-unsafe-links.
--compress-threads is capped at 8 on a daemon. --max-alloc=0 is rejected by both client and daemon in 3.5.0 (upstream restored it in 3.5.1, which trixie does not have yet), so remove it from your jobs.
hosts deny entries that cannot be resolved now block the connection instead of letting it through. A stale hostname in that list can lock out more clients than before.
proxy protocol = true without proxy protocol hosts now rejects every connection, and the daemon warns about it at startup.

Find every scheduled rsync job:

systemctl list-timers --all --no-pager
grep -rn rsync /etc/crontab /etc/cron.d/ /etc/cron.daily/ /var/spool/cron/crontabs/ 2>/dev/null
grep -rln rsync /etc/systemd/system/ /usr/local/bin/ 2>/dev/null

Do a dry run of each job by hand with the same options, and check the exit code:

rsync -a --dry-run --itemize-changes /srv/data/ backup@backup.example.net:/srv/backup/data/
echo "exit code: $?"

After the next scheduled run, check the logs for refused paths or failed units:

journalctl -u rsync --since today --no-pager
systemctl --failed --no-pager

If rsync copies are your only backup, this is a good time to add a second, versioned tool. The hardened restic setup with an append-only repository gives you snapshots that a compromised client cannot overwrite.

Harden rsyncd

If you don't need the daemon, turn it off. This stops anything that pulls from port 873:

systemctl disable --now rsync

If you do need it, run transfers as a dedicated unprivileged user, chroot every module, keep modules read-only and limit which hosts can connect. Warning: if you already run rsyncd, back up your existing /etc/rsyncd.conf and /etc/rsyncd.secrets before you change anything. Replacing the secrets file with an empty one locks out every client that uses auth users after the next restart. The commands below only create the secrets file if it does not exist yet:

[ -e /etc/rsyncd.conf ] && cp -a /etc/rsyncd.conf /etc/rsyncd.conf.bak
[ -e /etc/rsyncd.secrets ] && cp -a /etc/rsyncd.secrets /etc/rsyncd.secrets.bak
useradd --system --no-create-home --shell /usr/sbin/nologin rsyncd
[ -e /etc/rsyncd.secrets ] || install -m 600 -o root -g root /dev/null /etc/rsyncd.secrets

uid = rsyncd
gid = rsyncd
use chroot = yes
read only = yes
list = no
reverse lookup = no
max connections = 4
timeout = 600

[mirror]
    path = /srv/mirror
    comment = read-only mirror for the backup host
    hosts allow = 192.0.2.10 198.51.100.0/24
    auth users = backupuser
    secrets file = /etc/rsyncd.secrets

Notes on this config:

use chroot = yes makes chroot mandatory. With the default, the daemon tries to chroot but keeps going if that fails. CVE-2026-53784 was exactly a module escape when chroot was not in use.
hosts allow matches client IPs. With reverse lookup = no, use IPs and CIDRs, not hostnames. That also avoids the unresolvable-name problem fixed by CVE-2026-70452.
timeout and max connections are both unlimited (0) by default. Setting them limits the damage from stalled or flooding clients.
Don't enable proxy protocol unless a load balancer sits in front of the daemon. If you do enable it, also set proxy protocol hosts.
The secrets file holds backupuser:password lines. strict modes is on by default and rejects a world-readable file.

Restart the daemon (this drops active transfers) and test from an allowed client:

systemctl restart rsync
rsync --list-only rsync://backupuser@backup.example.net/mirror/

On top of that, filter TCP 873 so only the backup hosts can reach it. A fragment for the default inet filter input chain:

tcp dport 873 ip saddr { 192.0.2.10, 198.51.100.0/24 } accept
tcp dport 873 drop

Debian's unit already sets ProtectSystem=full, PrivateDevices=on and NoNewPrivileges=on. You can restrict it further with a drop-in, as described in sandboxing systemd services with systemd-analyze.

For SSH targets, give every backup key a forced command restricted to one directory, for example command="rrsync -ro /srv/backup". Combine that with the key restrictions from hardening SSH on Debian 13. Keep in mind that rrsync was itself affected (CVE-2026-53783). A forced command is a second layer and does not replace the patch.

What to watch next

Bookworm: the tracker shows Debian 12 as vulnerable to these CVEs. Watch the tracker page for rsync or debian-security-announce for a fixed package.
Regressions: upstream released 3.5.1 on 21 Sep 2026 with fixes for path-handling regressions, and forky/sid already have it. If your trixie jobs fail after the upgrade, check the tracker for a follow-up advisory before you change your jobs.
Logs: after the upgrade, more connections refused by hosts deny or more refused symlinked destinations in the logs come from the stricter checks. They can also show you a misconfiguration you didn't know about.

Takeaways

On trixie, upgrade to rsync 3.5.0+ds1-0+deb13u1. DSA-6527-1 fixes 33 CVEs.
Use ss -tlnp 'sport = :873', systemctl status rsync and a grep of authorized_keys to find out whether a host runs the daemon, accepts SSH transfers or only uses the client.
Restart rsync.service and check that /proc/PID/exe no longer shows (deleted).
Dry-run every cron job and timer that uses rsync. Watch for refused symlinked destinations and stricter rrsync rules.
Configure rsyncd with use chroot = yes, a dedicated uid/gid, read only = yes, hosts allow and a firewall rule on port 873. If you don't need the daemon, disable it.
Bookworm has no fix yet. Restrict the daemon there until a fixed package ships.