Learn Rsync - Security & CVE 3.4.x
Covering rsync's important security chapter: 3.4.0 (Jan 2025) closed 33 vulnerabilities including 2 RCEs (CVE-2024-12084/12085), a heap buffer overflow, and the --safe-links fix, followed by the 3.4.3/3.4.4 patches, plus security best practices: always use rsync >=3.4.4, SSH + key auth, and never expose rsyncd without a firewall.
#Introduction
Every time you see rsync --version print 3.2.7, it should send an alarm signal. Because in January 2025, rsync issued the largest security release in its history: 3.4.0 closed 33 vulnerabilities, including 2 Remote Code Execution (RCE) flaws. Episode 13 is the most serious part of this series — we dissect what went wrong, what was fixed, and how to operate safely.
Why is rsync a target? Because it's almost certainly installed on every Linux server and is often exposed (port 873 for the daemon, or triggered via rsync-over-SSH). The wider the surface, the more attractive to attackers.
#Why Rsync Became a Target
Rsync is nearly three-decade-old C code that handles input from the network — protocol parsing, checksums, and paths. The combination of "old code + untrusted input" is the classic recipe for memory-safety vulnerabilities. Add the fact that the rsync daemon often runs with elevated privileges, and an RCE in rsync means an attacker can run code on your server.
#3.4.0: The Big Security Release
Rsync 3.4.0 (released January 2025) closed 33 vulnerabilities. This wasn't a feature release — it was a massive security cleanup. It included the two most-awaited RCE fixes.
#CVE-2024-12084 & CVE-2024-12085 (RCE)
| CVE | Type | Impact |
|---|---|---|
| CVE-2024-12084 | Heap buffer overflow while processing checksum data | RCE — an attacker can run arbitrary code |
| CVE-2024-12085 | Info leak — uninitialized stack data | Leaks process memory to the adversary |
CVE-2024-12084 is the most dangerous: a bug in checksum buffer handling lets an attacker who can speak the rsync protocol (e.g. a client initiating a connection to the daemon, or a malicious daemon contacted by a client) write past the heap boundary and execute code. CVE-2024-12085 passes stack data to the output — leaking sensitive process information.
Warning
CVE-2024-12084/12085 don't only concern publicly exposed daemons. The "client connecting to a malicious rsync server" scenario is also affected — for example, an old rsync version directed at an attacker's server can be exploited. That's why the patch must be applied on both sides, not just the exposed side.
#Heap Buffer Overflow and --safe-links
Besides the two RCEs, 3.4.0 fixed several other vulnerabilities:
- Additional heap buffer overflows in daemon data buffer handling.
- A fix for
--safe-links— the option that ignores symlinks pointing outside the transfer directory; its old implementation turned out to be bypassable. - Various integer overflow bugs, path handling issues, and small information leaks.
#3.4.3 and 3.4.4: The Follow-ups
Security didn't stop at 3.4.0. Follow-up releases kept patching:
| Release | Date | Main Content |
|---|---|---|
| 3.4.1 | 2025 | Regression & bug fixes |
| 3.4.2 | 2025 | Further bugfixes |
| 3.4.3 | 2025 | Patches CVE-2026-29518 (info leak) and others |
| 3.4.4 | June 8, 2026 | Bugfix & security — including CVE-2026-4361 and friends |
CVE-2026-29518 is another information leak closed in 3.4.3; 3.4.4 completes it with bugfix and security patches. The main lesson: "already using 3.4.x" alone isn't enough — you need the latest patch version.
#Best Practices
The operational rules you should take into production:
- Always use rsync ≥3.4.4. Check and update regularly; don't let old 3.2.x or 3.3.x versions linger.
- Use SSH + key auth for all sensitive data transfers — encryption and strong authentication in one layer (details in episode 14).
- Don't expose rsyncd to the internet without a firewall. Port 873 must sit behind a firewall, VPN, or SSH tunnel.
- Run the daemon with a minimal user (
uid/giddedicated,use chroot = yes) — not root. - Follow least privilege:
read onlymodules unless writes are truly needed, secrets files atchmod 600.
Tip
Build a habit: every month, run rsync --version on all servers and compare with the latest release (check download.samba.org/pub/rsync/NEWS). Add this to your audit checklist — we make it part of the production checklist in episode 22.
#Checking and Updating
Check the version and update:
rsync --version | head -1
sudo apt update && sudo apt install rsync # Debian/Ubuntu
sudo dnf update rsync # RHEL/FedoraIf your distro doesn't provide 3.4.4 in its stable repo (old LTS distros), other options: use a static build compiled from source, or install from a newer repo. Never accept an old rsync just because "it's been running for years" — security changes.
#Closing
In this episode you've understood the most important security chapter in rsync's history.
Key takeaways:
- 3.4.0 (Jan 2025): 33 CVEs closed — including 2 RCEs (CVE-2024-12084 heap overflow, CVE-2024-12085 info leak).
- Patches apply on both sides of a transfer, not just the exposed side.
- 3.4.3 patches CVE-2026-29518; 3.4.4 (June 8, 2026) closes more (CVE-2026-4361 etc.).
- Best practice: rsync ≥3.4.4, SSH + key auth, don't expose rsyncd without a firewall.
- Audit versions periodically via
download.samba.org/pub/rsync/NEWS.
In episode 14 we harden the transport: SSH hardening & key auth — key-based auth, -e ssh with strict options (no passwords), restrict (no-port-forwarding) for rsync-only accounts, and why a daemon without TLS should be wrapped in an SSH tunnel. See you in episode 14!