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.
5 steps from start to impact.
Identify public rsyncd module
rsync rsync://target/ to list available modules. The attack needs a public daemon module that does not require authentication for reads.- Target exposes rsyncd on TCP 873 to the attacker's network
- Module is configured without authentication (anonymous read access)
- 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
Establish receiver session and request file
- Attacker has network connectivity and read permission on the module
- Sender runs rsync <= 3.5.1 with delta-transfer enabled (default)
- Anonymous read may be disabled; many modules require
auth usersor host allow/deny - Some modules are write-only or not readable
Send crafted weak checksum list
hash_search() repeatedly performs expensive strong-checksum work at consecutive offsets.- Attacker can craft or obtain a PoC implementing rsync receiver protocol with malicious checksum generation
- Protocol version negotiation stays within vulnerable path
- 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
hash_search load.Multiply concurrent connections
- Server has no
max connectionslimit or per-IP rate limiting - Attacker can originate many connections (botnet or repeated sockets)
- rsyncd.conf
max connectionscan cap concurrent sessions, but defaults may be unlimited - CPU exhaustion requires sustained connections; attack ends when connections close
Service outage
- Sustained attack connections continue
- No automated kill/restart of rsync daemon
- Restarting rsync clears in-progress attacks; an attacker must maintain pressure
- This is availability-only; no persistence or lateral movement
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.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.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.- 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.
The supporting signals.
| In-the-wild status | Not observed; not in CISA KEV as of current reporting. VulDB records no known exploitation. |
|---|---|
| PoC availability | No public PoC. VulDB exploit price $0-$5k with 0.00+ reliability; no GitHub repos named after CVE-2026-119741 in search results. |
| EPSS score / percentile | No published EPSS; treat as low likelihood until FIRST publishes a score. |
| KEV status | Not KEV-listed; no active exploitation evidence. |
| CVSS vector | CVSS: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 versions | rsync through 3.5.1; all prior versions vulnerable. |
| Fixed version | No patched version identified in search results; monitor rsync upstream advisory. |
| Scanning/exposure | Shodan/Censys regularly report thousands of TCP 873 hosts worldwide, but only a small subset expose unauthenticated readable public modules. |
| Disclosure date | 2026-11-03 |
| Reporting researcher | Omar Elsayed (credited by VulnCheck). |
Sources.
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.
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.
#!/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