CVE-2026-70464: 
rsync vulnerability analysis and mitigation

CVE-2026-70464 is a denial-of-service vulnerability in the rsync daemon that allows unauthenticated remote attackers to exhaust all available connection slots by stalling the handshake process. It affects rsync versions 2.0.0 through 3.4.4, with version 3.5.0 being the first patched release. The vulnerability was published on August 13, 2026, and was reported independently by Chamal De Silva and Michal Ruprich of Red Hat QE. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Microsoft MSRC).

The root cause is improper resource allocation without throttling (CWE-770 / CWE-400): the rsync daemon forks a child process per connection but imposes no handshake deadline before or spanning the read_args() calls. Two distinct stall forms exist: (1) stalling before module selection by sending a line with no terminator — this pins a process and file descriptor but does not consume a module slot; and (2) stalling after module selection by trickling NUL-terminated arguments into read_args() one byte at a time, which holds a max connections slot and can make the module unavailable to legitimate clients. The pre-existing timeout module parameter did not mitigate this because set_io_timeout() executed after the vulnerable read_args() calls, and the default timeout value is 0 (disabled). The fix introduces a separate handshake deadline with a non-zero built-in default, active before the greeting and spanning both read_args() calls, and bounds the early-protocol argument count (GitHub Advisory).

Successful exploitation renders the rsync daemon unavailable to legitimate clients by exhausting all configured connection slots. Because no authentication is required and the attack works against anonymous modules, any internet-exposed rsync daemon is at risk. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue, but it can completely block backup, synchronization, and file-transfer operations that depend on the rsync daemon (GitHub Advisory, Microsoft MSRC).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time. The vulnerability is rated automatable by NVD SSVC, meaning it can be scripted without user interaction. The EPSS score is approximately 0.57%, indicating a currently low probability of exploitation in the near term. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog as of the time of this report (GitHub Advisory, Microsoft MSRC).

1. Reconnaissance: Identify internet-facing rsync daemons running versions 2.0.0–3.4.4 using network scanners (e.g., Shodan, Censys, or nmap with the rsync service probe on TCP port 873).
2. Establish multiple connections: Open a large number of simultaneous TCP connections to port 873 on the target rsync daemon, up to or exceeding the daemon's configured max connections limit.
3. Complete the @rsyncd greeting: For each connection, send the initial @rsyncd protocol greeting to advance past the first handshake stage, ensuring the forked child process is created.
4. Stall before module selection (pre-slot variant): Send a line with no newline terminator, causing the child to block indefinitely waiting for input — consuming a process and file descriptor without triggering any timeout.
5. Stall after module selection (slot-exhaustion variant): Send a valid module name to claim a max connections slot, then trickle NUL-terminated arguments into read_args() one byte at a time at the minimum rate to avoid any I/O timeout, holding the slot open.
6. Exhaust connection slots: Repeat steps 3–5 across all open connections until all max connections slots are consumed, causing the daemon to reject new connection attempts from legitimate clients with a 'max connections' error (GitHub Advisory).

• Network: Large number of simultaneous inbound TCP connections to port 873 from one or more source IPs; connections that remain open for an unusually long duration without completing a transfer.
• Process: Elevated number of rsync daemon child processes in a waiting/sleeping state with no active I/O; processes persisting far beyond the expected handshake window.
• Logs: Rsync daemon logs showing repeated connections that never progress to module authentication or file transfer; log entries indicating max connections limit reached for a module, blocking legitimate clients.
• System: Unusually high number of open file descriptors associated with the rsync daemon process (/proc/<pid>/fd); system resource exhaustion metrics (process table, file descriptor limits) correlating with rsync daemon activity (GitHub Advisory).

The primary remediation is to upgrade rsync to version 3.5.0 or later, which introduces a handshake deadline with a non-zero default that spans both read_args() calls (GitHub Release). Distribution-specific patches are available from SUSE (SUSE-SU-2026:3634-1, SUSE-SU-2026:3657-1), Fedora, and other Linux vendors. As interim workarounds: restrict access to the rsync daemon (TCP port 873) via firewall rules to trusted IP ranges; configure a low max connections value per module combined with IP-based rate limiting at the network perimeter; and deploy a load balancer or firewall that enforces TCP connection timeouts to prevent indefinite stalling (GitHub Advisory, Microsoft MSRC).

The vulnerability was reported independently by two researchers — Chamal De Silva (connection-holding variant) and Michal Ruprich of Red Hat QE (the read_args() argument-trickle variant) — and was addressed in a release described by the rsync project as a "major security release." Multiple Linux distributions including SUSE and Fedora issued security advisories and updated packages shortly after disclosure. No significant social media controversy or broader media coverage has been identified beyond standard security advisory channels (GitHub Advisory, GitHub Release).