---
id: "CVE-2026-119741"
kind: "vulnerability"
aliases: ["CVE-2026-119741"]
title: "rsync: crafted checksums let a client exhaust sender CPU"
severity: "high"
cvss: 8.7
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["linux", "package", "rsync", "self-hosted"]
not_affected_if: ["auth-required", "no-public-daemon", "ssh-only"]
published_at: "2026-11-03T16:17:21+00:00"
first_seen_at: "2026-11-03T16:21:42+00:00"
updated_at: "2026-11-03T16:23:43+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119741", "first_seen_at": "2026-11-03T16:21:42+00:00"}]
---

# rsync: crafted checksums let a client exhaust sender CPU

rsync through 3.5.1 has a flaw in the delta-transfer sender's hash_search() in match.c where a malicious receiver can force unbounded strong-checksum work. An unauthenticated attacker pulling from a public rsync daemon module can exhaust sender CPU across concurrent connections, causing denial of service.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed version with `rsync --version`, and compare it against the fixed release in the product ranges.
- Look for rsync daemon modules (`rsyncd.conf`) exposed to the internet and reachable without authentication.

## Fix

- rsync: move to a release newer than `3.5.1` (fixed version not stated in the sources; check the linked patch).

## Timeline

- 2026-11-03T16:21:42+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-119741

## Documents

- [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/rsync-through-3.5.1-denial-of-service-via-hash-search-checksum-collisions
- [fix] Patch: github.com https://github.com/RsyncProject/rsync/commit/a7404a9a633cff28ee1602f328b9c3fa69cdbd04

## From the sources

rsync through 3.5.1 contains a denial of service vulnerability in the delta-transfer sender's hash_search() in match.c that allows malicious receivers to trigger unbounded strong-checksum work at consecutive offsets. Unauthenticated attackers pulling from a public daemon module can supply weak checksums colliding with consecutive rolling windows plus non-matching strong checksums, exhausting sender CPU across concurrent connections.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_