CVE-2024-12085

What it actually does

Manipulating the s2length parameter during rsync checksum comparisons causes a byte-wise comparison against uninitialized stack memory, resulting in one byte of stack data being leaked to the attacker per invocation.

Why it matters to the business

Organizations using rsync for file synchronization risk gradual leakage of sensitive in-memory data such as credentials, encryption keys, or configuration secrets over repeated transfers, increasing exposure in automated backup or replication workflows.

How an attack unfolds

An attacker positions themselves as a malicious rsync peer (client or server) and crafts checksum responses with an oversized or manipulated s2length value; during normal file comparison the victim rsync process compares the supplied checksum against uninitialized stack bytes and returns the leaked byte, allowing the attacker to repeat the process to reconstruct larger memory regions.

How to fix it

Upgrade rsync to the commit 6c8ca91c731b7bf2b081694bda85b7dadc2b7aff or later; rebuild packages from the patched source and redeploy across all synchronization endpoints.

How to confirm the fix worked

Verify rsync binary or source matches or exceeds commit 6c8ca91c731b7bf2b081694bda85b7dadc2b7aff; run regression tests that exercise checksum comparison paths with varying file sizes.

Typical attack path

1. Establish rsync connection to target as client or induce target to connect to attacker-controlled server
2. Trigger file-listing and checksum phase for chosen paths
3. Supply crafted checksum metadata with manipulated s2length
4. Receive one leaked stack byte per comparison iteration
5. Repeat across multiple files or sessions to accumulate memory contents

How to detect it

Review rsync daemon and client logs for repeated checksum phase entries on the same files, unusual connection patterns from untrusted peers, or processes exhibiting high numbers of short-lived rsync sessions; correlate with memory-dumping indicators if available.

What your security team should do

• Immediately inventory all rsync deployments and schedule upgrade to the fixed commit
• Restrict rsync usage to authenticated, encrypted channels and least-privilege accounts until patched
• Monitor rsync-related network traffic for anomalous checksum lengths or repeated short transfers that could indicate probing