Key details

  1. 4 November 2026 release: rsync 3.5.2.
  2. CVE-2026-119741, High, affects versions through 3.5.1 according to upstream.
  3. A malicious receiver can cause strong-checksum calculations at each byte offset.
  4. Repeated public daemon connections can exhaust sender CPU.
  5. The issue remained after mitigation of CVE-2026-70453.
  6. Upstream recommends upgrading to 3.5.2; downstream backport status must be checked.

What builders should take away

  1. Inventory rsync versions on senders and public daemon hosts.
  2. Upgrade to 3.5.2 or confirm a distro backport of CVE-2026-119741.
  3. Limit exposure to untrusted receiver connections where feasible.
  4. Do not conflate CPU exhaustion with remote code execution or confirmed exploitation.
  5. Monitor CPU spikes and daemon connection patterns while patching.

What changed

On 4 November 2026, the rsync project released version 3.5.2 and published an advisory for CVE-2026-119741 (High). The issue survived the earlier CVE-2026-70453 mitigation. A malicious receiver can supply weak checksums that collide across consecutive rolling windows, causing the sender to calculate a full strong checksum at each byte offset. Repeated connections to a public rsync daemon can exhaust host CPU. Upstream states versions through 3.5.1 are affected and recommends upgrading to 3.5.2.

Why it matters

Backup and mirroring workflows often assume that only the receiver is at risk from malicious sender data. This flaw reverses that trust direction: a hostile receiver can impose expensive work on a sending host. Administrators operating rsync daemons or allowing untrusted peers to initiate transfers should verify the actual installed package and their distribution's security backport status, not assume that older distro version numbers are necessarily unpatched.

The receiver controls expensive checksum work

rsync's delta-transfer protocol uses rolling weak checksums to find matching blocks and strong checksums to confirm matches. Upstream describes an adversarial receiver able to create repeated weak-checksum collisions, forcing expensive strong hashing at each offset. The security page identifies CPU exhaustion across repeated public daemon connections as the risk, not data theft or arbitrary code execution.

Who needs to act

Systems running rsync through 3.5.1 in the affected sender-side transfer scenario should upgrade to 3.5.2 or a distribution build containing the fix. Internet-accessible daemon configurations and workflows accepting transfers from untrusted receivers deserve priority. Package version alone may not reveal downstream backports; consult distribution advisories.

What changed beyond security

The 3.5.2 release also adds process-priority controls for local and remote transfers and other fixes since 3.5.1. These are separate from the high-severity checksum vulnerability.

Evidence limits

The rsync project provides a direct dated advisory and release announcement. The record does not establish exploitation in the wild, measured prevalence, or fixed versions for each distribution. The new CVE is distinct from the 33 vulnerabilities addressed in rsync 3.5.0 in August.

What to watch next

  • Debian, Ubuntu and other distro security backport advisories.
  • Any upstream regression reports after 3.5.2.
  • Independent technical reproduction and exploitation reports.

Still unclear

  • No confirmed in-the-wild exploitation established.
  • Affected package and fixed backport versions vary by distribution and were not individually verified.
  • No independently reproduced performance or attack-volume measurements were obtained.

Sources

Direct reading behind this dossier.

3 sources
Rsync security advisories
rsync project primary

Direct upstream affected-version, mechanism, severity and mitigation details.

rsync 3.5.2 released
rsync project primary

Release date, security fix and process-priority change.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment