Introduction
An integer overflow in rsync's compressed token decoder lets a malicious sender silently extract sensitive process memory from any rsync receiver running version 3.4.2 or earlier. The leaked data can include plaintext passwords, environment variables, and enough memory layout information to defeat ASLR. That turns what looks like a routine file sync into a serious information disclosure channel.
Technical information
The vulnerability is in the compressed token decoder inside the rsync receiver process. As it processes compressed data tokens from the sender, the decoder accumulates values in a 32-bit signed counter. The root cause is that nothing checks this counter for overflow. A malicious sender can craft a sequence of compressed tokens that pushes the counter past its maximum value until it wraps, which is an integer overflow (CWE-190).
After the overflow, the decoder uses the corrupted counter value to calculate buffer offsets for later read operations. The receiver then reads from memory outside the intended buffer boundaries, an out-of-bounds read (CWE-125), and sends that data back to the sender as part of the normal rsync protocol exchange.
Attack flow
- The attacker opens an rsync connection to a target receiver and acts as the sending side of the transfer.
- The attacker sends specially crafted compressed tokens that incrementally manipulate the 32-bit signed counter in the decoder without triggering any existing validation.
- At a calculated point, the counter overflows and the decoder computes an out-of-bounds memory offset.
- The receiver process reads from the out-of-bounds location and returns the contents to the attacker over the network in its protocol response.
- The attacker collects the leaked memory. It may contain environment variables (often holding API keys and configuration secrets), plaintext passwords, heap and stack data that reflects application state, and library memory pointers.
Impact breakdown
| Data type exposed | Security implication |
|---|---|
| Environment variables | May contain API keys, configuration secrets, and internal network details. |
| Passwords | Direct credential theft leading to unauthorized access. |
| Heap and stack data | Exposure of application state and sensitive user data processed by the daemon. |
| Library memory pointers | Bypasses ASLR protections to enable secondary code execution attacks. |
Leaking library memory pointers is especially damaging because it directly undermines Address Space Layout Randomization. An attacker who knows where shared libraries are mapped in the receiver's address space can build reliable exploits for secondary vulnerabilities that ASLR would otherwise mitigate.
Severity scoring
Exploitation needs no user interaction and only low privileges. The attack vector is network based, and the attack complexity is low.
| Source | Framework | Score | Key metrics |
|---|---|---|---|
| GitHub Security Advisory | CVSS 3.1 | 8.1 (High) | Network Vector, Low Complexity, High Confidentiality, High Availability |
| VulnCheck | CVSS 4.0 | 6.1 (Medium) | Network Vector, Low Complexity, High Vulnerable System Confidentiality |
The scores differ because the two CVSS frameworks weight confidentiality and availability impacts differently. Organizations that rely on automated, score-based patching thresholds should be aware of the gap.
Affected systems and versions
All rsync versions up to and including 3.4.2 are affected. Version 3.4.3 fixes the vulnerability.
An rsync deployment is vulnerable when the receiver accepts connections from untrusted senders and uses compression. That includes rsync daemons exposed to the network that have not explicitly disabled compression in their configuration.
If you cannot patch right away, disable compression on rsync daemons by adding the following to rsyncd.conf:
refuse options = compress
This keeps the daemon from using the vulnerable compressed token decoder.
Vendor security history
CVE-2026-43618 is one of several recent rsync security issues. Another, CVE-2026-41035, is a use-after-free vulnerability affecting rsync versions 3.0.1 through 3.4.1. Multiple memory-safety bugs in recent releases show how hard it remains to maintain a C codebase that does complex protocol parsing and compression.
The rsync project, maintained by Wayne Davison and hosted under the RsyncProject organization on GitHub, responded promptly with version 3.4.3, which includes the combined security fixes. Security researcher Omar Elsayed is credited with discovering CVE-2026-43618.
