rsync through 3.5.1 Denial of Service via hash_search() Checksum Collisions
Affects rsync through 3.5.1 when syncing files with large even block sizes, causing sender CPU exhaustion. No fixed version is listed in the checked facts.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fix or patch referenced
- Who is exposed
- Not reported
Do first: Apply the patch listed under Evidence.
- Exploitation0/40No signal
- Exposure20/25No login or user action needed, CISA rates it automatable · Data gap: Advisories don't say whether default setups are affected
- Reach?/20Reach: unknown (data gap). No tracked technology or package matched
- Severity8.7/10CVSS 8.7
- No patch0/5No signal
What would change the score
- Would score about 74 if added to CISA KEV
- Would score about 69 if CISA's SSVC rates exploitation active
- Would score about 34 if advisories confirm default setups are exposed
CVE-2026-119741 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 8.7 (high) and affects rsync; a fix or patch is referenced.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 29/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fix or patch referenced
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
rsync, a widely used file synchronization tool, is affected, and a malicious client that connects to a public rsync server can craft data that forces the server to spend excessive CPU time on checksum calculations. This can exhaust the server's processing resources across multiple connections, causing a denial of service.
Read the original description
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.
What to do
Apply the patch listed under Evidence.
Workaround: Use an odd --block-size (for example --block-size=131071) to avoid weak-checksum collisions on repeated-byte files.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- RsyncProject rsync
through 3.5.1
Evidence 5
- Patch
- Patch
- Repository
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-119741
Is CVE-2026-119741 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
Certain file contents can cause many different blocks to produce the same weak rolling checksum. The sender then spends extra CPU computing strong checksums at nearly every byte offset, which slows the transfer down heavily.Source: github.com
Which versions are affected by CVE-2026-119741?
rsync: through 3.5.1.Source: cve.now feed data
Am I affected, and how do I check?
Versions of rsync through 3.5.1 are in scope, and the issue depends on the block size used, with large power-of-2 or even block sizes such as 65536 and 131072 being the case described. Check your version with rsync --version and the block size used in your transfer commands or settings.Source: github.com
How do I fix CVE-2026-119741?
No fixed version is listed in the checked facts, so no upgrade target can be given from them. As a workaround, use an odd --block-size such as --block-size=131071 to avoid weak-checksum collisions on repeated-byte files.Source: github.com