← Back to Feed CACHED · 2026-11-04 07:40:34 · CACHE_KEY CVE-2026-119741
CVE-2026-119741 · CWE-407 · Disclosed 2026-11-03

rsync delta-transfer sender hash_search weak-checksum collision CPU exhaustion

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A public librarian is forced to re-index the same shelf from every starting point when readers send colliding book requests

During rsync delta transfer, the sender's hash_search() in match.c tries to match receiver-supplied rolling checksums. A malicious receiver can send weak checksums that collide with consecutive rolling windows but fail strong checksums, causing the sender to repeatedly recompute strong checksums at consecutive offsets. Affected versions are rsync through 3.5.1. Unauthenticated attackers pulling from a public daemon module can trigger this and exhaust sender CPU across concurrent connections.

The vendor HIGH 7.5 rating overstates real-world exposure. The flaw is availability-only—no code execution, no data exfiltration—and only bites rsync daemon modules that are reachable without authentication. Most enterprise rsync runs over SSH rather than rsyncd, and public daemon modules are typically mirrors with connection limits or network allowlists. For most defenders this is a MEDIUM, not a HIGH.

"Remote unauth rsync daemon CPU exhaustion—real but only for exposed anonymous modules; treat as MEDIUM for most enterprises."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify public rsyncd module

Attacker scans for TCP 873 or uses rsync rsync://target/ to list available modules. The attack needs a public daemon module that does not require authentication for reads.
Conditions required:
  • Target exposes rsyncd on TCP 873 to the attacker's network
  • Module is configured without authentication (anonymous read access)
Where this breaks in practice:
  • Modern OS images do not enable rsyncd by default
  • Enterprise firewalls typically block 873 from untrusted networks
  • Most enterprise rsync deployments use SSH transport instead of daemon mode
Detection/coverage: Shodan/Censys queries for port 873 banners; rsync logs module access but often not centrally collected.
STEP 02

Establish receiver session and request file

Attacker connects as a receiver and initiates delta-transfer for a file inside the module. The sender expects the receiver to send block checksums; a vulnerable sender accepts attacker-controlled checksum lists.
Conditions required:
  • Attacker has network connectivity and read permission on the module
  • Sender runs rsync <= 3.5.1 with delta-transfer enabled (default)
Where this breaks in practice:
  • Anonymous read may be disabled; many modules require auth users or host allow/deny
  • Some modules are write-only or not readable
Detection/coverage: rsyncd logs the connection; SIEM may alert on unusual rsync activity if monitored.
STEP 03

Send crafted weak checksum list

Attacker sends a custom block-checksum set where weak checksums collide with consecutive rolling windows while strong checksums deliberately do not match. The vulnerable hash_search() repeatedly performs expensive strong-checksum work at consecutive offsets.
Conditions required:
  • Attacker can craft or obtain a PoC implementing rsync receiver protocol with malicious checksum generation
  • Protocol version negotiation stays within vulnerable path
Where this breaks in practice:
  • No public weaponized exploit in VulDB/GitHub at time of research; requires protocol understanding
  • Strong-checksum work per request is bounded per file but amplifies with file size/window count
Detection/coverage: No signature-based network IDS for this specific checksum pattern; CPU profiling of the rsync process may show abnormal hash_search load.
STEP 04

Multiply concurrent connections

Attacker opens many simultaneous receiver sessions, each forcing sender CPU burn. Without per-IP connection throttling, sender CPU saturates and legitimate sync jobs time out.
Conditions required:
  • Server has no max connections limit or per-IP rate limiting
  • Attacker can originate many connections (botnet or repeated sockets)
Where this breaks in practice:
  • rsyncd.conf max connections can cap concurrent sessions, but defaults may be unlimited
  • CPU exhaustion requires sustained connections; attack ends when connections close
Detection/coverage: Host CPU/load alerts; connection count anomalies via netstat/ss; rsync process CPU can be observed.
STEP 05

Service outage

Sender becomes unresponsive; all rsync-dependent operations such as backups or file distribution fail until the attack stops or the service is restarted.
Conditions required:
  • Sustained attack connections continue
  • No automated kill/restart of rsync daemon
Where this breaks in practice:
  • Restarting rsync clears in-progress attacks; an attacker must maintain pressure
  • This is availability-only; no persistence or lateral movement
Detection/coverage: Availability monitors, backup job failure alerts.
03 · Compensating Control

1
MEDIUM 5.5→LOW 2.0
SEVERITY REDUCED
Disable anonymous public rsync modules or restrict access to trusted IPs — Eliminates the unauthenticated public reachability precondition. If a public mirror is required, add auth users and hosts allow; use a firewall to allow only trusted source IPs. No noisgate mitigation SLA for MEDIUM; schedule as a hardening change within your normal change window. This leaves authenticated/internal rsync vulnerable but removes the unauthenticated vector.
2
MEDIUM 5.5→IGNORE 0.0
SEVERITY REDUCED
Apply upstream patch or upgrade past 3.5.1 when available — The real fix is in hash_search; upgrade as soon as a patched version is released. No patch is currently identified, so monitor rsync upstream advisory. For MEDIUM verdict, patch within 365 days per noisgate remediation SLA.
3
MEDIUM 5.5→LOW 3.5
SEVERITY REDUCED
Limit concurrent connections and per-IP rate — Set max connections = 2 or a per-IP firewall rate limit. This reduces the amplification step but not the per-request CPU burn. No noisgate mitigation SLA for MEDIUM; implement as routine hardening.
4
MEDIUM 5.5→MEDIUM 5.0
Enable host-based monitoring and alerting for rsync CPU and connections — Detect abuse and trigger kill/restart actions to reduce outage duration. This does not prevent initial CPU exhaustion. Implement immediately for visibility; no noisgate mitigation SLA.
What doesn't work
  • Standard web application firewalls (WAF) or HTTP proxies cannot inspect rsync protocol on TCP 873.
  • EDR agents on the sender may detect a CPU spike but will not block the protocol-level attack; they only aid response.
  • Disabling delta-transfer globally is not practical; it is core to rsync efficiency and not a supported knob for most deployments.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNot observed; not in CISA KEV as of current reporting. VulDB records no known exploitation.
PoC availabilityNo public PoC. VulDB exploit price $0-$5k with 0.00+ reliability; no GitHub repos named after CVE-2026-119741 in search results.
EPSS score / percentileNo published EPSS; treat as low likelihood until FIRST publishes a score.
KEV statusNot KEV-listed; no active exploitation evidence.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — network, low complexity, no privileges, availability high. VulnCheck reports CVSS 4.0 base 8.7.
Affected versionsrsync through 3.5.1; all prior versions vulnerable.
Fixed versionNo patched version identified in search results; monitor rsync upstream advisory.
Scanning/exposureShodan/Censys regularly report thousands of TCP 873 hosts worldwide, but only a small subset expose unauthenticated readable public modules.
Disclosure date2026-11-03
Reporting researcherOmar Elsayed (credited by VulnCheck).

Sources.

  1. VulDB — CVE-2026-119741
  2. VulDB — RsyncProject rsync denial of service
  3. Rapid7 — CVE-2026-119741
  4. DevGuard Vulnerability Database — CVE-2026-119741
  5. VulnCheck Advisory — rsync through 3.5.1 DoS via hash_search()
  6. NVD — CVE-2026-119741
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

  • Baseline adjustment: vendor HIGH 7.5 reflects network unauth availability, but not real exposure—rsyncd public daemon is a minority deployment.
  • Deployment exposure: most enterprise rsync uses SSH transport; only public read-only modules are exploitable without prior internal access.
  • Impact ceiling: availability-only CPU exhaustion; no confidentiality/integrity impact, no code execution, no data loss.
  • Role multiplier: rsync in file-distribution/backup roles can cause backup outages and file-sync delays, but the worst plausible outcome is service downtime—not domain, fleet, or supply-chain compromise. No high-value-role floor applies.
  • Exploit status: no public PoC, no KEV listing, no observed in-the-wild exploitation as of reporting.

Why not higher?

Because the vulnerability does not compromise data or execute code; it only exhausts CPU. It requires unauthenticated access to a public rsync daemon module, a configuration that is rare in enterprise networks. No active exploits or KEV listing means it does not warrant CRITICAL or HIGH for most defenders.

Why not lower?

Unauthenticated remote CPU exhaustion is still serious for public rsync mirrors and internal file-sync servers with weak access controls. The attack can be launched from a single host and amplify across concurrent connections, causing real availability loss. MEDIUM is appropriate despite low exposure.

06 · Verification

Crowdsourced verification payload.

Run on each rsync server (Linux/macOS) as root or a user with read access to process list and config. Invocation: bash check_rsync_cve_2026_119741.sh. Outputs VULNERABLE, PATCHED, or UNKNOWN with exit codes 0/1/2.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-119741 checker for rsync daemon hosts
set -u

VULN_VER="3.5.1"

if ! command -v rsync >/dev/null 2>&1; then
  echo "UNKNOWN: rsync not installed"
  exit 2
fi

ver=$(rsync --version | awk 'NR==1{print $3}')
if [ -z "$ver" ]; then
  echo "UNKNOWN: cannot parse rsync version"
  exit 2
fi

# Determine if daemon mode is configured/running
daemon=0
if [ -f /etc/rsyncd.conf ]; then daemon=1; fi
if pgrep -x rsync >/dev/null 2>&1; then daemon=1; fi
if command -v ss >/dev/null 2>&1 && ss -ltn 2>/dev/null | grep -q ':873 '; then daemon=1; fi

# Version comparison: if max of (VULN_VER, ver) is VULN_VER, then ver <= VULN_VER
max=$(printf '%s\n' "$VULN_VER" "$ver" | sort -V | tail -1)
if [ "$max" = "$VULN_VER" ]; then
  vuln_ver=1
else
  vuln_ver=0
fi

if [ "$vuln_ver" -eq 0 ]; then
  echo "PATCHED: rsync version $ver is newer than $VULN_VER"
  exit 1
fi

if [ "$daemon" -eq 1 ]; then
  echo "VULNERABLE: rsync version $ver <= $VULN_VER and daemon/config/port 873 found"
  exit 0
else
  echo "UNKNOWN: rsync version $ver <= $VULN_VER but no daemon mode detected on this host"
  exit 2
fi