rsync 3.5.2 Fixes CVE-2026-119741: Anonymous Clients Can Exhaust a Public rsync Daemon's CPU With Colliding Checksums

Cyber · 2026-11-09 · By H.A

rsync 3.5.2 fixes CVE-2026-119741, a hash_search() flaw that lets a malicious receiver force a server running any version through 3.5.1 into endless failing strong-checksum work, with no account needed on public daemon modules.

The rsync project has released rsync 3.5.2, which fixes CVE-2026-119741. The flaw lets a malicious client tie up a server's CPU with checksum work that can never succeed. Every version through 3.5.1 is affected. If you run a public rsync daemon module, which is common for Linux mirrors, open-source projects and backup targets, anyone can trigger it without an account.

The flaw affects availability only and does not expose or change data. VulnCheck, which assigned the CVE, scores it 8.7 under CVSS 4.0 and 7.5 under CVSS 3.1. Linux distributions have started shipping the update.

What Happened

rsync 3.5.2 came out in early November 2026. Alongside the security fix, it adds new options for controlling the CPU and disk priority of transfers, and improves matching for large sparse files and files with lots of repeated data. Slackware has already pushed 3.5.2 packages for Slackware 15.0 and -current, and other distributions are expected to follow.

This is a separate bug from CVE-2026-70453, an older quadratic-time worst case in the same code that a malicious sender could use to exhaust a receiver's CPU. That one was fixed in rsync 3.5.0. CVE-2026-119741 works in the opposite direction.

Technical Details

rsync saves bandwidth with its delta-transfer algorithm. The receiver splits its existing copy of a file into blocks and sends two checksums for each block:

• a cheap weak (rolling) checksum, and
• an expensive strong checksum.

The sender slides a window across its version of the file, one byte at a time, and computes the rolling checksum at each position. It only computes the expensive strong checksum when the weak checksum matches a block. Normally that happens rarely, so the process is fast.

CVE-2026-119741 sits in hash_search() in match.c and abuses that shortcut. A malicious receiver sends weak checksums chosen to collide with consecutive rolling windows in the sender's file, and pairs them with strong checksums that will never match. Now nearly every position triggers the expensive strong-checksum calculation, and every calculation fails. Researchers say a handful of simultaneous connections is enough to exhaust the server's CPU.

When a client downloads from a daemon, the server is the sender and the client is the receiver, so the attacker only needs to connect and request a file.

Who Is Affected

• Public rsync daemons (rsync://, TCP port 873) running 3.5.1 or older are the main target. Anonymous modules let anyone attack them without credentials.
• Authenticated daemons and rsync over SSH are not singled out in the disclosure. Because the bug is in the sender's matching logic, it is safest to assume that anyone who can already connect and download, such as a semi-trusted user of a shared backup server, could trigger it.
• Clients that only push files to servers they trust are not the target of this bug.

Patch Status

The fix is in rsync 3.5.2. Distribution packages may use their own version numbers or backport the patch to an older version, so check your distribution's security tracker, not just the version string.

Check what you are running:

rsync --version | head -1
# Debian/Ubuntu
apt list --installed 2>/dev/null | grep -i '^rsync'
# RHEL/Fedora
rpm -q rsync

New in 3.5.2: Priority Controls

The release adds --nice and --no-nice options. They can set CPU and I/O scheduling priority for the local process, the remote process or both:

• A daemon client can ask for CPU nice 19, idle I/O priority, or both.
• rrsync, the restricted wrapper for SSH, accepts local priority reductions only.
• If a requested local change is unsupported or denied, rsync prints a warning and carries on with the transfer.
• Remote settings need a peer that supports them. Local-only settings also work with older peers.

These options help with ordinary resource contention. They do not fix the vulnerability.

What To Do Now

1. Upgrade to rsync 3.5.2 or your distribution's patched package, starting with internet-facing daemons.
2. Find exposed daemons. List the hosts listening on port 873 and question every public module:

ss -ltnp | grep ':873'
rsync rsync://localhost/   # list the modules this daemon exports

1. Reduce the blast radius until you patch. In rsyncd.conf, use max connections to cap simultaneous sessions per module and hosts allow to restrict who can connect. Firewall port 873 so only the networks that need it can reach it.
2. Run the daemon under resource limits. A systemd drop-in keeps one runaway daemon from starving the rest of the host:

# /etc/systemd/system/rsync.service.d/limits.conf
[Service]
CPUQuota=50%
Nice=10

Then run systemctl daemon-reload && systemctl restart rsync.

1. Watch for the symptoms: rsync processes pinned at 100% CPU for long periods, and many connections from a small set of addresses, especially to large files.

Why It Matters

rsync is in the background of a huge amount of infrastructure: Linux distribution mirrors, CPAN and CRAN-style archives, backup systems and deployment pipelines. A bug that lets anonymous users burn a mirror's CPU with a few connections is a cheap way to slow downloads, delay backups or cause outages. This is the second CPU-exhaustion fix in the same hash_search() code in a short time, a reminder that "it only uses a bit more CPU" bugs in widely deployed daemons are worth patching quickly, even when no data is at risk.