# rsync CPU Exhaustion via Algorithmic Complexity in hash_search() (CVE-2026-119741) - Fixed in 3.5.2

> rsync versions through 3.5.1 contain an inefficient algorithmic complexity flaw (CWE-407) in the delta-transfer sender's hash_search() in match.c. A malicious receiver can send colliding weak checksums paired with non-matching strong checksums, forcing the sender into unbounded strong-checksum computation and CPU exhaustion. No authentication is required against public daemon modules. Fixed in rsync 3.5.2.

- **Published:** 2026-11-04T08:27:13Z
- **Last reviewed:** 2026-11-04T08:27:13Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5221
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5221.png
- **ID:** TL-2026-5221
- **Severity:** HIGH (CVSS 7.5)
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 (1 shown free below) · **IOCs:** 12 (1 shown free below)
- **CVEs:** CVE-2026-119741, CVE-2026-70453

## Description

CVE-2026-119741 is a denial-of-service vulnerability in rsync's delta-transfer sender. In hash_search() in match.c, the sender slides a rolling weak checksum across the file and, on each weak-checksum hit, computes a strong checksum to confirm the block match. NVD and VulnCheck describe the flaw as allowing malicious receivers to trigger unbounded strong-checksum work at consecutive offsets. A malicious receiver transmits weak checksums that collide with successive rolling windows, paired with strong checksums that never match. The sender repeats the expensive strong-checksum computation at every byte offset (full 64-128 KiB block checksums at large block sizes) and its CPU is exhausted.

The impact is availability only. CVSS v3.1 is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and CVSS v4.0 is 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N). The weakness is CWE-407 (Inefficient Algorithmic Complexity). Per the Help Net Security report, no authentication is needed when targeting a public rsync daemon module, because serving files to pulling clients is the module's intended function. Every release through 3.5.1 is affected; NVD lists the CPE range cpe:2.3:a:samba:rsync up to and including 3.5.1.

The upstream fix is commit a7404a9a633cff28ee1602f328b9c3fa69cdbd04 (PR #1132 in RsyncProject/rsync, authored by seks99x, reviewed and merged by steadytao on 2026-10-20). It does two things. First, it tracks the strong checksum of the last failed chain entry (last_false_sum2) and unlinks subsequent duplicate entries with identical weak checksum, offset and length, so they are not re-walked and do not consume the 1024-entry MAX_CHAIN_LEN cap; SUMFLG_SAME_OFFSET handling is preserved for --inplace mode. Second, once four consecutive 1-byte offsets hit weak-checksum collisions with every chain entry failing (consecutive_false_offsets), the sender advances a full block instead of testing each byte. That bounds the work at O(N/B) instead of O(N*B). The PR adds two regression tests (testsuite/hashsearch-collision-skip_test.py and hashsearch-dup-chain_test.py) covering chains beyond MAX_CHAIN_LEN, interleaved duplicate chains, boundary offsets, and both standard and --inplace modes.

The PR was framed first as a performance regression fix: sparse files and disk images with repeated constant blocks at 64K/128K block sizes hit the same code path non-maliciously (issues #1115 and #217). Benchmarks in the PR show rsync 3.5.1 taking 13s (1 MiB literal data) and 69s (4 MiB literal data) on sparse tests versus 0.4s and 11s (0 literal) on 3.4.1; the patch restores 3.4.1 parity. PR discussion concluded the problem is an incomplete fix of the earlier CVE-2026-70453 and warranted separate CVE tracking for downstream distributions. The author also noted that choosing an odd --block-size (coprime to 65536) gives all 256 constant-byte fills distinct weak checksums, avoiding the benign collision case.

rsync 3.5.2 is tagged on GitHub with the security fix (GHSA-56w4-j8c7-xvrw) and adds --nice/--no-nice process-priority options for CPU and I/O priority across local and remote processes; the GitHub release page is dated 2026-11-03 and Help Net Security reported the release on 2026-11-04. VulnCheck assigned the CVE and published its advisory on 2026-11-03, crediting Omar Elsayed. This is a different issue from CVE-2026-70453 (VulnCheck advisory 2026-08-13, rsync <= 3.4.4, fixed in 3.5.0, GHSA-8x5r-mjx8-83hv, credit heyciao and dr-who), an earlier hash_search() quadratic-time DoS. The sources do not state exploitation in the wild, a public weaponized PoC, or any attributed threat actor; upstream publishes only the collision regression tests.

## MITRE ATT&CK

- T1595.002 Vulnerability Scanning
- T1190 Exploit Public-Facing Application
- T1133 External Remote Services
- T1499.004 Application or System Exploitation

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**rsync Daemon Long-Lived Low-Volume Session (CVE-2026-119741 hash_search DoS) - Exploitation [SPL]** (`TL-2026-5221-SPL-001`)

Detects rsync daemon sessions (rsync through 3.5.1) that stay open for 5+ minutes while the sender transmits under 1 MiB. This is the observable signature of CVE-2026-119741 (CWE-407): a malicious receiver sends colliding weak checksums with non-matching strong checksums, so hash_search() in match.c repeats strong-checksum work at every byte offset instead of sending data. Session duration is derived per rsyncd PID from syslog connect/module/summary lines. No exploitation in the wild is reported; this is a behavioural alert on the attack symptom for public daemon modules (TCP/873).

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1190, T1133, T1499.004, T1499
- **Data sources:** linux_syslog, rsyncd_logs
- **Severity:** high
- **Confidence:** medium

### Splunk SPL

````spl
index=os sourcetype=syslog earliest=-24h rsyncd
```CVE-2026-119741 rsync through 3.5.1 hash_search() CPU exhaustion: the daemon session stays open for minutes while almost no data is sent```
| eval pid=if(match(_raw,"rsyncd.[0-9]+."),replace(_raw,".*rsyncd.([0-9]+).*","\1"),null())
| eval src_ip=if(match(_raw," from [^ ]+ .[0-9a-fA-F.:]+."),replace(_raw,".* from [^ ]+ .([0-9a-fA-F.:]+).*","\1"),null())
| eval module=if(match(_raw,"rsync (on|to) [^/ ]+/"),replace(_raw,".*rsync (on|to) ([^/ ]+)/.*","\2"),null())
| eval bytes_sent=if(match(_raw,"sent [0-9]+ bytes"),tonumber(replace(_raw,".*sent ([0-9]+) bytes.*","\1")),null())
| eval total_size=if(match(_raw,"total size [0-9]+"),tonumber(replace(_raw,".*total size ([0-9]+).*","\1")),null())
| where isnotnull(pid)
| stats min(_time) as first_seen max(_time) as last_seen values(src_ip) as src_ip values(module) as module max(bytes_sent) as bytes_sent max(total_size) as total_size by host pid
| where isnotnull(bytes_sent)
| eval duration_s=last_seen-first_seen
| where duration_s>=300 AND NOT bytes_sent>=1048576
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| table first_seen host pid module src_ip duration_s bytes_sent total_size
````

### Microsoft KQL

```kql
// CVE-2026-119741 rsync through 3.5.1: long-lived, low-volume rsyncd sessions (hash_search CPU exhaustion)
Syslog
| where TimeGenerated > ago(24h)
| where ProcessName =~ "rsyncd"
| extend SrcIp = extract(@" from [^ ]+ .([0-9a-fA-F.:]+).", 1, SyslogMessage),
         Module = extract(@"rsync (?:on|to) ([^/ ]+)/", 1, SyslogMessage),
         BytesSent = tolong(extract(@"sent ([0-9]+) bytes", 1, SyslogMessage)),
         TotalSize = tolong(extract(@"total size ([0-9]+)", 1, SyslogMessage))
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            SrcIps = make_set_if(SrcIp, isnotempty(SrcIp)),
            Modules = make_set_if(Module, isnotempty(Module)),
            BytesSent = max(BytesSent), TotalSize = max(TotalSize)
            by Computer, ProcessID
| where isnotnull(BytesSent)
| extend DurationSec = datetime_diff("second", LastSeen, FirstSeen)
| where DurationSec >= 300 and BytesSent < 1048576
| project FirstSeen, Computer, ProcessID, Modules, SrcIps, DurationSec, BytesSent, TotalSize
| order by DurationSec desc
```

### Sigma

```yaml
title: rsync Daemon Module Access Logged - Precursor To CVE-2026-119741 hash_search DoS
id: 5b2f0c7e-8d41-4a36-9c1e-3f7a2d6b9e14
status: experimental
description: Single-event companion to the SPL/KQL duration logic. Flags rsyncd syslog lines recording a client accessing a daemon module. On rsync through 3.5.1 any reachable public module can be abused by a malicious receiver to exhaust sender CPU via colliding weak checksums (CVE-2026-119741, CWE-407). Correlate with session duration and bytes sent, or use a Sigma event_count correlation, before alerting.
references:
  - https://www.vulncheck.com/advisories/rsync-through-3.5.1-denial-of-service-via-hash-search-checksum-collisions
  - https://github.com/RsyncProject/rsync/pull/1132
  - https://github.com/RsyncProject/rsync/releases/tag/v3.5.2
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/04
tags:
  - attack.initial-access
  - attack.t1190
  - attack.t1133
  - attack.impact
  - attack.t1499
  - attack.t1499.004
  - cve.2026-119741
logsource:
  product: linux
  service: syslog
detection:
  rsyncd_process:
    - 'rsyncd'
  module_access:
    - 'rsync on '
    - 'rsync to '
  condition: rsyncd_process and module_access
falsepositives:
  - Legitimate mirror clients and backup jobs pulling from public or internal rsync modules
  - Monitoring probes that connect to the daemon
level: low
```

**Known false positives:**

- Legitimate very large transfers over slow links where the client is idle-polling or the file list build is slow, producing long sessions with few bytes sent
- Mirror clients repeatedly checking large, unchanged trees: long session, little data sent
- Sparse files and disk images at 64K/128K block sizes hit the same hash_search() path benignly on rsync through 3.5.1 (upstream issues 1115 and 217)

**Tuning notes:** Adjust the 300s duration and 1 MiB bytes_sent thresholds to your module baselines. If rsyncd logs to a file (log file = ...) instead of syslog, change index/sourcetype and the PID extraction. Exclude known mirror/backup source IPs via src_ip. Confirm rsync version with 'rsync --version' on matching hosts (<= 3.5.1 is vulnerable, 3.5.2 fixed). Sessions killed before the summary line is logged are not matched; pair with the CPU and symptom detections (002, KQL-002).

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Repeated [indicator] Daemon Module Sessions From One External Source (CVE-2026-119741) - Exploitation [KQL] (locked: unlock with TL Creds)
- [indicator] Daemon Availability Degradation Symptoms (CVE-2026-119741) - Post-Exploitation Impact [KQL] (locked: unlock with TL Creds)
- [indicator] Daemon Module Enumeration From External Source (CVE-2026-119741) - Reconnaissance [KQL] (locked: unlock with TL Creds)
- [indicator] Daemon Process Started On Vulnerable Host (CVE-2026-119741 Exposure) - Exploitation Surface [Sigma] (locked: unlock with TL Creds)
- [indicator] Client Run With 64 KiB+ Block Size Forcing Large Strong Checksums (CVE-2026-119741) - Post-Exploitation Impact [Sigma] (locked: unlock with TL Creds)
- Non-rsync Process Connecting To [indicator] Daemon Port 873 (CVE-2026-119741 Attack Client) - C2 / Network Activity [Sigma] (locked: unlock with TL Creds)
- [indicator] Sender Process Sustained High CPU (CVE-2026-119741 hash_search) - Post-Exploitation Impact [SPL] (locked: unlock with TL Creds)
- External Scanning / Fan-Out Against [indicator] Daemon Port TCP/873 - Reconnaissance and Exposure [SPL] (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sample indicators (1 of 12)

Defanged, TLP:CLEAR.

- File hash: `a7404a9a633cff28ee1602f328b9c3fa69cdbd04`

Full set of 12 indicators unlocks with TL Creds: https://threadlinqs.com/tl-creds

## Sources

- [Open-source file sync tool rsync 3.5.2 fixes a CPU exhaustion flaw](https://www.helpnetsecurity.com/2026/11/04/rsync-3-5-2-released/)
- [NVD - CVE-2026-119741](https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-119741)
- [VulnCheck Advisory: rsync through 3.5.1 Denial of Service via hash_search checksum collisions](https://www.vulncheck.com/advisories/rsync-through-3.5.1-denial-of-service-via-hash-search-checksum-collisions)
- [RsyncProject/rsync PR #1132 - Bound hash search collision work](https://github.com/RsyncProject/rsync/pull/1132)
- [RsyncProject/rsync commit a7404a9 - Bound hash search collision work](https://github.com/RsyncProject/rsync/commit/a7404a9a633cff28ee1602f328b9c3fa69cdbd04)
- [RsyncProject/rsync v3.5.2 release](https://github.com/RsyncProject/rsync/releases/tag/v3.5.2)
- [RsyncProject/rsync repository](https://github.com/RsyncProject/rsync)
- [rsync NEWS file (3.5.2 changelog)](https://download.samba.org/pub/rsync/NEWS#3.5.2)
- [VulnCheck Advisory: rsync Algorithmic Complexity DoS via hash_search (CVE-2026-70453, related earlier issue fixed in 3.5.0)](https://www.vulncheck.com/advisories/rsync-algorithmic-complexity-dos-via-hash-search)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5221