CVE-2026-43618

What it actually does

Rsync 3.4.2 and earlier contain an integer overflow in the compressed-token decoder. A malicious sender can cause a 32-bit signed counter to wrap, making the receiving rsync process read beyond the intended buffer and return unintended process memory. The exposed memory may include environment variables, credentials, heap and stack contents, and memory addresses that weaken ASLR and can support follow-on exploitation. The issue is network-reachable in rsync workflows where a vulnerable receiver processes compressed data from an attacker-controlled or compromised sender; exploitation requires the attacker to be able to act as a sender in a permitted rsync exchange.

Why it matters to the business

Successful exploitation can expose secrets handled by rsync processes, including passwords, tokens, configuration values, and operational metadata. This can lead to credential theft, data exposure, lateral movement, and preparation for more damaging compromise. The current public exploitation signal is low: EPSS is 0.78%, exploit maturity is listed as none, and the issue is not in CISA KEV or known ransomware use, but the impact is high enough to prioritize remediation wherever rsync is exposed to untrusted peers or used for automated backup, deployment, or synchronization jobs.

How an attack unfolds

An attacker first identifies a system or workflow where a vulnerable rsync receiver will accept data from a sender the attacker controls or has compromised. The attacker initiates or waits for an rsync transfer using compression, then sends a crafted compressed token stream designed to overflow the decoder's 32-bit signed counter. When the receiver processes the malformed compressed data, its bounds calculations become incorrect and it reads memory outside the expected buffer. The attacker receives leaked process memory in the rsync protocol response. The attacker can then search the leaked data for credentials, environment variables, secrets, heap or stack values, and library pointers. Memory addresses may be used to reduce exploit mitigations such as ASLR and improve reliability of later attacks against the same process or host.

How to fix it

Upgrade rsync to a vendor-provided fixed release newer than 3.4.2 as soon as it is available for the operating system or distribution in use. Because no exact fixed version was provided in the input, rely on the relevant OS, appliance, container image, or package maintainer advisory and confirm that the installed build includes the CVE-2026-43618 fix. If immediate upgrade is not possible, reduce exposure by disabling rsync access from untrusted peers, restricting rsync to trusted networks or VPNs, enforcing strong authentication, limiting which systems may act as senders, and disabling compression for rsync workflows where feasible. Rotate credentials or secrets that may have been present in rsync process environments on systems exposed to untrusted senders.

How to confirm the fix worked

Confirm the installed rsync version and vendor patch status on all systems, containers, appliances, and backup/deployment images that include rsync. Validate that no deployed package reports version 3.4.2 or earlier unless the vendor has backported the specific fix. Review rsync daemon and job configurations to confirm that only trusted peers can initiate transfers and that compression is disabled or unnecessary where mitigation is being used. Perform a controlled rsync transfer after patching to verify expected functionality. Where exposure existed, review logs for unexpected rsync sessions, failed protocol streams, abnormal transfer errors, unusual remote peers, and large or repeated compressed transfers from untrusted sources.

Typical attack path

1. Identify rsync services, scripts, backup jobs, or synchronization workflows using rsync 3.4.2 or earlier.
2. Determine whether the vulnerable system can be made to act as an rsync receiver from an attacker-controlled or compromised sender.
3. Ensure the transfer path uses rsync compression or otherwise reaches the compressed-token decoder.
4. Send a crafted compressed token stream that triggers the integer overflow in the receiver.
5. Collect unintended process memory returned by the vulnerable receiver.
6. Extract secrets, environment variables, credentials, memory pointers, or other sensitive artifacts from the leaked data.
7. Use recovered secrets or memory layout information for lateral movement, privilege escalation, or follow-on exploitation.

How to detect it

There may be no reliable application-level log entry when this vulnerability is successfully exploited, because the primary effect is memory disclosure during protocol processing. Hunt for evidence of suspicious rsync activity from the date of exposure onward using rsync daemon logs, SSH authentication logs, system logs, EDR process telemetry, firewall and proxy logs, and packet captures where available. Focus on rsync receiver activity involving untrusted or unusual senders, transfers using compression, repeated failed or short-lived rsync sessions, protocol data stream errors, unexpected connections to rsync daemon port 873/TCP, and rsync-over-SSH commands from unfamiliar accounts or source addresses. Also inspect systems for subsequent misuse of secrets that could have been leaked from rsync process memory, such as unexpected SSH logins, use of backup/deployment credentials, new scheduled jobs, unauthorized file synchronization, or lateral movement shortly after suspicious rsync sessions. Named threat actors and KEV activity were not provided, and public exploitation maturity is currently listed as none, so detection should be behavior-based rather than IOC-only.

What your security team should do

• Inventory all rsync installations, including servers, clients, backup systems, deployment tooling, containers, appliances, and embedded distribution packages.
• Prioritize patching systems that receive rsync data from external, partner, user-controlled, or otherwise less-trusted senders.
• Restrict rsync network access using firewalls, allowlists, VPNs, or SSH forced commands so only trusted peers can send data to vulnerable receivers.
• Disable rsync compression where operationally acceptable until patched.
• Review rsync daemon logs, SSH logs, backup job logs, and network telemetry for suspicious or unexpected rsync activity since publication.
• Rotate credentials, tokens, and secrets that may have been available in rsync process environments on exposed systems.
• Monitor vendor advisories for the exact fixed package versions and confirm whether distribution packages contain backported fixes even if the upstream version string appears unchanged.