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

Key facts for rsync hash_search DoS

Detection coverage for rsync hash_search DoS

As of 2026-11-04, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5221 across Splunk SPL, Microsoft KQL and Sigma, covering 12 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: rsync Daemon Long-Lived Low-Volume Session (CVE-2026-119741 hash_search DoS) - Exploitation [SPL]

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

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

// 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

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).

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

Indicators of compromise for rsync hash_search DoS

As of 2026-11-04, Threadlinqs Intelligence tracks 12 indicators of compromise for TL-2026-5221.

Sample indicators (1 of 12)

• File hash: a7404a9a633cff28ee1602f328b9c3fa69cdbd04

Defanged, TLP:CLEAR. Full set of 12 indicators: unlock with TL Creds.

How rsync hash_search DoS works

No authentication is required against public daemon modules. Fixed in rsync 3.5.2.

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 techniques by tactic:

Initial Access

T1133 External Remote Services; T1190 Exploit Public-Facing Application

Impact

T1499.004 Application or System Exploitation

Reconnaissance

T1595.002 Vulnerability Scanning

Remediation for rsync hash_search DoS

Patches

• rsync 3.5.2 (upstream commit a7404a9a633cff28ee1602f328b9c3fa69cdbd04, PR #1132, GHSA-56w4-j8c7-xvrw)
• Apply distribution backports of the fix when they become available

Immediate actions

• Upgrade rsync to 3.5.2 or later on every host that acts as a sender (rsync daemon, or the remote side of pull operations)
• Inventory internet-exposed rsync daemons (TCP/873) and prioritize patching public modules
• Monitor sender-side rsync processes for sustained high CPU with low data transfer

Workarounds

• Where patching is delayed, do not expose rsync daemon modules to untrusted networks
• Use the new rsync 3.5.2 --nice/--no-nice options only to limit the effect of CPU pressure; they do not fix the flaw
• For benign sparse-file/disk-image slowdowns, an odd --block-size value (coprime to 65536) avoids constant-fill weak-checksum collisions per the PR author; this is not a security control against a crafted receiver

Longer-term hardening

• Restrict rsync daemon modules to authenticated users or trusted networks via hosts allow/deny and firewall rules
• Apply per-module connection limits and resource limits (max connections, cgroup/ulimit CPU controls) on rsync servers
• Track rsync as a managed package in the software inventory so future security releases are patched promptly

Affected and fixed versions

• RsyncProject — rsync
  Vulnerable versions: through 3.5.1
  Fixed in: 3.5.2

Timeline of rsync hash_search DoS

• 2026-08-13 locked-ioc-10 publishes CVE-2026-70453, an earlier hash_search() quadratic-time DoS (locked-ioc-12 <= 3.4.4, fixed in 3.5.0, credit heyciao and dr-who); a separate issue later judged in PR discussion to be incompletely fixed
• 2026-10-20 RsyncProject/locked-ioc-12 PR #1132 'Bound hash search collision work' merged upstream (commit a7404a9), adding duplicate-chain unlinking and a 4-collision block-skip in hash_search()
• 2026-11-03 GitHub release v3.5.2 published referencing CVE-2026-119741 / GHSA-56w4-j8c7-xvrw, with new process-priority options
• 2026-11-03 NVD record last modified (21:10 UTC) with CVSS 3.1 7.5 and CVSS 4.0 8.7 metrics and CPE range for locked-ioc-12 up to and including 3.5.1
• 2026-11-03 CVE-2026-119741 published (16:17 UTC) in NVD; locked-ioc-10 advisory describes the DoS in locked-ioc-12 through 3.5.1 (credit: locked-ioc-9)
• 2026-11-04 Help Net Security reports the locked-ioc-12 3.5.2 release and the CPU exhaustion flaw, noting no authentication is needed against public daemon modules

Sources cited for rsync hash_search DoS

• NVD - CVE-2026-119741 NVD (NIST) · Advisory · 2026-11-03
• VulnCheck Advisory: rsync through 3.5.1 Denial of Service via hash_search checksum collisions vulncheck.com · Advisory · 2026-11-03
• VulnCheck Advisory: rsync Algorithmic Complexity DoS via hash_search (CVE-2026-70453, related earlier issue fixed in 3.5.0) vulncheck.com · Advisory · 2026-08-13
• rsync NEWS file (3.5.2 changelog) download.samba.org · Vendor report · 2026-11-03
• RsyncProject/rsync PR #1132 - Bound hash search collision work GitHub · Code repository · 2026-10-20
• RsyncProject/rsync commit a7404a9 - Bound hash search collision work GitHub · Code repository · 2026-10-20
• RsyncProject/rsync v3.5.2 release GitHub · Code repository · 2026-11-03
• RsyncProject/rsync repository GitHub · Code repository · 2026-11-04
• Open-source file sync tool rsync 3.5.2 fixes a CPU exhaustion flaw Help Net Security · News · 2026-11-04

More in vulnerability

• Critical Rails Active Storage Flaw (GHSA-f3w6-w445-fwh9) Lets Attackers Write Server Files via Crafted ImageMagick Uploads
• Google Chrome 157 Security Update Fixes 213 Bugs Including 7 Critical Vulnerabilities (CVE-2026-121156, CVE-2026-121247, CVE-2026-121229, CVE-2026-121246, CVE-2026-121035, CVE-2026-121203, CVE-2026-121126)
• CVE-2025-42611: Authentication bypass in multiple MikroTik RouterOS services via improper certificate validation (shared trust store)
• CVE-2026-25599: Missing Authentication, Clear-Text Transmission and Stored XSS in Orca Heat Pumps and Orca User Portal
• SolarWinds Dameware Command Injection Vulnerability (CVE-2026-28336)