CVE-2026-70461

Executive Summary

CVE-2026-70461 is a heap out-of-bounds write vulnerability in rsync, affecting versions 3.2.5 through 3.5.0 (exclusive). The flaw resides in the add_implied_include() function, which under-counts trailing backslashes when sizing destination buffers for files-from entries, enabling a remote unauthenticated attacker to write one attacker-controlled byte past a heap allocation boundary. Exploitation requires access to an rsync daemon exposing a read-only module, making this a high-severity (CVSS 8.2) network-accessible flaw with integrity impact and potential for service disruption. No patch is currently available from any tracked source, leaving affected deployments in a vulnerable state.

Technical Analysis

Vulnerability Class: CWE-787 (Out-of-bounds Write)

Affected Component: The add_implied_include() function, which is invoked during processing of files-from entries supplied to an rsync daemon. The files-from feature (--files-from) allows clients to specify a list of files to retrieve from a daemon module.

Root Cause: The vulnerability stems from an integer/string-length miscalculation in add_implied_include(). When a files-from entry contains both an interior backslash (used as a path separator) and a trailing backslash, the function under-counts the trailing backslash when computing the destination buffer size for path normalization or implied include expansion. This results in a heap allocation that is one byte too small. The subsequent buffer write operation, which copies the path content including the trailing backslash, writes one attacker-controlled byte past the end of the allocated heap buffer.

Attack Mechanism: The NVD description specifies that the trigger condition is a files-from entry containing both an interior and a trailing backslash. For example, an entry such as dir/file\ (with a trailing backslash) would cause the under-counting behavior. The trailing backslash is meaningful to rsync's path handling logic — it often denotes a directory — and the under-count occurs during buffer sizing.

Attack Surface: Any rsync daemon (rsyncd) exposing a module — even a read-only module — is vulnerable. The default rsync daemon configuration may enable anonymous access or require authentication depending on the auth users and secrets file configuration options. However, the NVD description explicitly notes that unauthenticated attackers can trigger the vulnerability against a read-only rsync daemon module, implying that the default access controls may not prevent exploitation in all configurations.

Scope of the Write: The out-of-bounds write is limited to exactly one byte, and that byte is attacker-controlled. This constraint affects exploitability: a single-byte heap overflow generally does not permit arbitrary code execution directly, but it can corrupt adjacent heap metadata or application data, potentially leading to a crash (availability impact) or, in more sophisticated scenarios, heap grooming to achieve a controlled write. The CVSS vector (C:N/I:L/A:H) reflects this: no confidentiality impact, low integrity impact, and high availability impact.

Affected versions: rsync 3.2.5 through 3.4.x (before 3.5.0). The NVD description does not provide a definitive list of patched versions beyond 3.5.0; the official fix is expected in 3.5.0, but this release has not been confirmed as available or published at the time of this report.

Exploitation Scenarios

No public PoC or exploit code is available (PoC/Exploit: UNKNOWN). The following attack chain is inferred from the vulnerability class and the trigger conditions described in the NVD entry.

Step 1 — Reconnaissance/Target Identification: Attackers scan for exposed rsync daemons by probing TCP port 873 (default rsync port) or by using Shodan/Censys searches. Network-accessible rsync services can be identified via banners, protocol negotiation, or by attempting rsync --list-only rsync://target/module/ connections. Shodan dorks for identifying vulnerable instances are provided in the metadata section.

Step 2 — Triggering the Flaw: The attacker connects to the target rsync daemon and initiates a transfer using the --files-from option. The files-from list is supplied either via a local file or via a daemon module path (e.g., rsync -av --files-from=evil.txt rsync://target/readonly_module/). The attacker crafts the files-from entries to include filenames or paths that contain both an interior backslash and a trailing backslash. For instance, an entry like dir1\file\ or just dir\ would satisfy the trigger condition. The crafted list is transmitted to the daemon, which begins processing the entries through the vulnerable add_implied_include() function.

Step 3 — Payload/Execution at Vulnerability-Class Level: During processing of the crafted files-from entry, the function under-counts the trailing backslash when sizing the heap destination buffer. A one-byte heap buffer overflow occurs, writing a single attacker-controlled byte past the buffer boundary. The attacker controls the content of the entry (and thus the byte written), but cannot directly control the memory layout or the immediate execution flow at this stage. The corrupt byte lands in adjacent heap space, potentially corrupting a chunk header, an adjacent buffer, or heap metadata — which can lead to a segmentation fault (crash) or, with sufficient heap grooming, a controlled corruption.

Step 4 — Post-Exploitation Impact:

• Availability (CVSS A:H): The most likely outcome is a daemon crash, causing denial of service for legitimate users of the rsync service. Repeated exploitation can keep the service down.
• Integrity (CVSS I:L): In theory, a sophisticated attacker could leverage the single-byte write to modify path-handling data structures, potentially tricking the daemon into writing files outside the module's designated root directory or altering access control decisions. However, this is speculative given the write constraints.
• Confidentiality (CVSS C:N): No confidentiality impact is expected directly from this vulnerability.

Note: The exploitation scenario above is generic and based strictly on the NVD description. No public PoC is available; the attack chain is inferred from the vulnerability class.

Impact Assessment

Business Impact: rsync is widely deployed for file synchronization, backup automation, mirroring, and content distribution (including for web server document roots). Affected organizations rely on rsync for data pipeline integrity, and a crash could halt backup or replication jobs, delaying recovery and creating data freshness gaps.

Affected Systems:

• Any rsync daemon running versions 3.2.5 through 3.4.x, especially those exposed to the internet or untrusted networks.
• Read-only rsync modules are fully exploitable, so even conservative configurations (read-only, no uploads) are at risk.
• Unix-like systems (Linux, BSD, macOS) are primary targets; Windows builds of rsync are also affected if they use a vulnerable version.

Blast Radius: The flaw in add_implied_include() is present whenever files-from entries are processed; therefore, any rsync daemon accepting files-from lists is exposed. The CVSS base score is 8.2 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H: the attack requires no privileges and no user interaction, and exploitation does not require authentication. The availability subscore is high, reflecting the direct crash-inducing capability.

Data/System Exposure: The presence of the vulnerability in a read-only module means that even tightly-scoped rsync deployments are impacted. If the daemon is exposed to the public internet, the availability of the service is immediately at risk. Because the overflow is limited to a single byte, the likelihood of remote code execution is considered low without additional chained vulnerabilities or heap layout control.

Detection Guidance

Sigma Rule

title: Rsync Heap Overflow Attempt via Crafted Files-From Entries
id: 233a47f9-2c37-4f2a-86b7-8e4a2e107a6b
status: experimental
description: Detects rsync daemon log entries or process traces indicating a buffer overflow attempt related to files-from entries with trailing backslashes (CVE-2026-70461).
author: Valtersit Threat Intelligence
logsource:
  product: linux
  service: rsyncd
detection:
  selection_log:
    LogName: 'rsyncd'
    Message|contains|all:
      - 'files-from'
      - 'backslash'
  selection_crash:
    LogName: 'kernel'
    Message|contains: 'segfault'
  condition: selection_log or selection_crash
level: high
falsepositives:
  - Legitimate users passing unusual paths (rare)

YARA Rule

rule Rsync_Heap_Overflow_FilesFrom_Trailing_Backslash {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects strings in network payloads or process memory indicative of rsync files-from entries with trailing backslashes used to trigger CVE-2026-70461"
        cve = "2026-70461"
        score = 60
    strings:
        // Match rsync protocol daemon handshake / files-from markers
        $file_list_marker = "@RSYNCD:"
        $file_list_flag = "files-from"
        // Multiple backslash patterns that could trigger the overflow
        $bs1 = { 5C 5C } // double backslash "\\"
        $bs2 = { 2F 5C } // forward+backslash "/\"
        $bs3 = { 5C 2F } // backslash+forward "\/"
        condition:
            any of ($file_list*) and any of ($bs*)
}

Suricata IDS Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 873 (msg:"ET EXPLOIT Rsync CVE-2026-70461 Attempted Heap Overflow via Files-From Trailing Backslash"; flow:to_server,established; content:"@RSYNCD:"; fast_pattern; content:"files-from"; distance:0; content:"\\"; within:256; sid:704610001; rev:1; metadata:created_at 2026-01-01, updated_at 2026-01-01, cve 2026-70461, reference url https://nvd.nist.gov/vuln/detail/CVE-2026-70461;)

Elastic Detection

any where process.name == "rsync" and event.action == "segfault"
or any where process.name == "rsync" and message like "rsync: connection unexpectedly closed"
or any where process.name == "rsync" and message like "*buffer overflow*"

Splunk SPL Query

index=linux_os sourcetype=rsyncd OR sourcetype=rsyncd_log
(Message="*files-from*" AND Message="*backslash*")
OR (sourcetype=secure OR sourcetype=syslog AND Message="*rsync*segfault*")
| eval time = _time
| stats count by host, Message
| sort - count
| table _time, host, Message, count

Wazuh OSSEC Rule

<group name="rsync,">
  <rule id="704610" level="12">
    <decoded_as>syslog</decoded_as>
    <field name="program">^rsync</field>
    <match>segfault|core dumped|buffer overflow|connection unexpectedly closed</match>
    <description>Rsync daemon potential crash/overflow (CVE-2026-70461)</description>
    <group>rsync,vulnerability,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Status: UNPATCHED (patch confidence 0/4). No vendor patch, no release candidate, and no mitigation patch is available from any tracked source. The upstream rsync project has not yet published a fixed version (expected 3.5.0).

Immediate Mitigations (in order of preference):

1. Restrict network access: Block inbound TCP 873 from untrusted networks via firewall rules or network security groups. Only allow rsync access from known, authorized source IPs.
2. Disable or remove read-only modules: If a module does not need to serve the files-from feature, disable it entirely. For modules that remain active, disable the files-from functionality where possible — this typically requires modifying the daemon source or configuration since there is no built-in option to disable files-from; upstream may provide a runtime option in a later release.
3. Rate-limit and monitor: Implement connection rate-limiting and monitor rsync daemon access logs for suspicious files-from patterns (repeated entries with trailing backslashes).
4. Isolate the service: Place rsync daemons in a DMZ or on dedicated internal hosts — not on production application servers — to reduce the blast radius of a crash or potential compromise.
5. Authentication enforcement: Restrict daemon access to authenticated users only (set auth users and secrets file in rsyncd.conf). While authentication may not prevent exploitation (since unauthenticated triggers are viable per NVD), it reduces the attack surface by limiting who can connect.

Patch/Upgrade:

• Monitor the official rsync repository (https://github.com/RsyncProject/rsync) for the release of version 3.5.0 or a dedicated security fix. As of this writing, no such release exists.
• If the organization has PSRT or vendor agreements with downstream distributors (e.g., Red Hat, Debian, Ubuntu), track their security advisories for backported patches.
• Until a patch is available, treat all rsync daemons exposing modules over the network as high risk. If a module serves the internet or untrusted networks, consider disabling it until a fix is deployed.

Long-Term Hardening:

• Run rsync as an unprivileged user: Configure the rsync daemon to drop privileges (uid/gid in rsyncd.conf) so that a crash or partial compromise does not grant elevated privileges.
• Containerize or chroot: Run rsync daemons inside a chroot jail or container with minimal filesystem access to limit the impact of any future memory-corruption exploit.
• Network segmentation: Place rsync daemons behind a jump host or VPN access point, eliminating direct internet exposure.
• Adopt failover: If rsync is used for critical replication, implement a secondary sync mechanism (e.g., a mirror daemon) so that a crash does not block data copy operations.
• Subscribe to vendor security feeds: Enable notifications for rsync project releases and CVEs to receive prompt alerts when a patched version becomes available.
• Implement integrity checks on files-from processing: Consider wrapping the rsync daemon in a proxy that inspects files-from payloads for dangerous backslash patterns — a temporary measure, but functionally useful until the patch ships.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-70461
2. rsync Official Project Site: https://rsync.samba.org/ — track for 3.5.0 release announcement and security advisory.
3. rsync GitHub Repository (source & commit history): https://github.com/RsyncProject/rsync
4. CWE-787 Reference: https://cwe.mitre.org/data/definitions/787.html
5. No CISA KEV entry exists for this CVE as of this report; no known in-the-wild exploitation or threat actor campaigns have been publicly reported.