rsync security update fixes a CPU-exhaustion attack

Last updated: November 4, 2026

The rsync security update is out. Version 3.5.2 closes CVE-2026-119741, a flaw that allowed a connecting client to consume a server’s processing power through deliberately unproductive checksum calculations.

Every rsync version through 3.5.1 is affected. The reported impact is denial of service rather than file theft or corruption. Even so, an overloaded rsync server can disrupt backups, mirrors and unrelated jobs competing for the same CPU.

The release also introduces CPU and I/O scheduling controls, giving operators more control over how transfers affect other work on a busy machine.

How the checksum attack works

Rsync is an open-source utility for copying files locally and across networks. It is widely used for backups and mirroring software archives. Instead of retransmitting every byte, it breaks files into blocks and tries to send only the parts that changed.

That efficiency depends on a two-stage checksum process. The receiving side supplies a lightweight rolling checksum for each block and a stronger checksum for confirmation. The sender searches for matching blocks, computes the stronger checksum when the first stage suggests a match and confirms whether the blocks are identical.

CVE-2026-119741 exploits that final stage. In hash_search() in match.c, a malicious receiver can send weak checksums that repeatedly point to the same rolling window, paired with strong checksums that never match. The sender continues performing expensive calculations whose results are discarded.

The flaw therefore turns normal checksum work into an availability attack. A few malicious connections can consume enough CPU to slow or overwhelm legitimate transfers and other processes on the host.

VulnCheck, which assigned the identifier, describes the weakness as inefficient algorithmic complexity. It scores the issue 8.7 on CVSS 4.0 and 7.5 on CVSS 3.1, with the reported impact confined to availability.

Public daemon modules raise the stakes

Rsync can run through a public daemon module, where pulling files is the module’s intended purpose. That means someone reaching the daemon may be able to trigger the flaw without an account.

For public installations, the direct risk is service degradation rather than compromised data. CPU contention can make legitimate downloads slower, delay backups or interfere with unrelated applications sharing the host. The consequences depend on what else runs beside rsync and how much CPU headroom remains.

Version 3.5.2 also adds process-priority controls that can reduce this operational pressure. The new –nice and –no-nice options set CPU and I/O scheduling priority for the local process, the remote process or both. The CPU and I/O values compose independently, so an administrator can adjust one without automatically changing the other.

The controls have important boundaries. A daemon client may request CPU nice 19, idle I/O priority or both. The restricted SSH wrapper, rrsync, accepts local reductions alone. If a local change is unsupported or denied, rsync warns and continues the transfer. Remote scheduling requests require support from the peer, while local-only settings can work with older peers.

These options help manage contention. They do not remove the vulnerable checksum path.

Why it matters: patch first, then tune

The priority is to identify the rsync binary handling every exposed or internal transfer. Updating a workstation copy does not protect a server whose daemon still runs an affected release.

The severity scores also need to be read narrowly. An 8.7 on CVSS 4.0 and 7.5 on CVSS 3.1 indicate a serious availability risk. They do not mean the reported flaw lets an attacker read synchronized files, alter backups or execute code.

Scheduling controls offer a useful second layer, but they are not a substitute for remediation. A large legitimate synchronization can still compete for CPU and disk resources even after the vulnerability is fixed. Lowering a transfer’s priority may keep it from elbowing aside more urgent work, although the result depends on peer support and whether the requested setting was accepted.

Operators should also distinguish local from remote reductions. A local setting can operate without feature support from an older peer; a remote request may require an upgraded counterpart. A warning does not indicate that the transfer stopped, nor does it guarantee that the intended priority was applied.

In short, patch the service handling incoming connections, then use scheduling where appropriate to protect foreground jobs and other transfers.

Decision checklist

Use this sequence when reviewing an rsync deployment:

• [ ] Inventory rsync instances, including public daemon modules, internal servers, backup hosts and mirror infrastructure.
• [ ] Confirm the version serving each workload.
• [ ] Upgrade affected installations through 3.5.1 to version 3.5.2.
• [ ] Verify that the daemon or scheduled job launches the updated binary.
• [ ] Prioritize public daemon deployments, where clients may trigger the flaw without an account.
• [ ] Review whether transfers need independent CPU and I/O priority reductions.
• [ ] Check which side of each transfer can request and honour those settings.
• [ ] Investigate warnings about unsupported or denied local changes.
• [ ] Monitor CPU load, transfer latency and unusual concurrent connections after the update.
• [ ] Keep using version 3.5.2 rather than treating priority tuning as the primary fix.

What to watch after the upgrade

The immediate concern is CPU saturation, particularly on machines where rsync shares resources with backup monitoring, mirrors or other public services. Watch transfer latency and connection volume rather than expecting the vulnerability to alter synchronized data.

The scheduling additions deserve a separate test. Confirm whether the local endpoint, remote peer or both support the requested priority changes. That check matters because the two sides do not have identical permissions, and a continued transfer is not proof that every requested adjustment took effect.

Public daemons deserve attention first, but internal deployments should not be left on an affected version. The underlying weakness exists throughout the release line through 3.5.1, regardless of whether a particular installation normally handles anonymous users.

Bottom line: treat CVE-2026-119741 as a genuine denial-of-service risk, keep its confidentiality and integrity scope in check, and upgrade the rsync service handling incoming connections.

Key takeaways

• Upgrade every affected rsync installation to version 3.5.2, starting with public daemons.
• CVE-2026-119741 affects availability through CPU exhaustion, not file confidentiality or integrity.
• Use the new scheduling options to reduce contention, but remember that remote controls require compatible peers.
• Verify the running binary after updating; an installed copy elsewhere on the host does not establish the daemon’s version.
• Treat priority tuning as operational defence, not a replacement for patching the checksum flaw.