CVE-2024-12088 Overview
A path traversal vulnerability has been identified in rsync, the widely-used file synchronization utility. When using the --safe-links option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This validation gap allows a malicious rsync server to bypass the intended safety restrictions and write arbitrary files outside the designated synchronization directory.
Critical Impact
Attackers controlling a malicious rsync server can exploit this flaw to write arbitrary files to the client system, potentially leading to code execution, data corruption, or system compromise.
Affected Products
- Samba rsync (all vulnerable versions)
- Red Hat Enterprise Linux 6.0, 7.0, 8.0, 9.0, and 10.0
- Red Hat OpenShift Container Platform 4.0
- Red Hat Discovery 1.14
- Red Hat Enterprise Linux EUS 9.6
- AlmaLinux 8.0, 9.0, and 10.0
- Arch Linux
- Gentoo Linux
- NixOS
- SUSE Linux
- SmartOS
Discovery Timeline
- January 14, 2025 - CVE-2024-12088 published to NVD
- November 3, 2025 - Last updated in NVD database
Technical Details for CVE-2024-12088
Vulnerability Analysis
This vulnerability represents a path traversal flaw (CWE-22) in rsync's symbolic link handling when the --safe-links option is enabled. The --safe-links option is designed to protect rsync clients by ignoring symbolic links that point to locations outside the synchronization tree. However, the implementation contains a logic flaw where nested symbolic links are not properly validated.
When a malicious rsync server sends file metadata to a client, it can craft symbolic link destinations that themselves contain symbolic links. The rsync client performs validation on the initial symlink path but fails to recursively verify whether resolved components within that path also point to locations outside the allowed directory tree. This allows an attacker to chain symbolic links in a way that ultimately resolves to a path outside the intended synchronization directory.
The vulnerability is particularly concerning because the --safe-links option is specifically intended as a security control. Users who employ this option have an expectation of protection against symlink-based path traversal attacks, making this bypass especially impactful.
Root Cause
The root cause lies in insufficient recursive validation of symbolic link destinations in the rsync client. When processing symlinks with --safe-links enabled, the client checks whether the immediate target path is within the allowed directory tree. However, it does not account for scenarios where the target path itself contains embedded symbolic links that could redirect file operations to unauthorized locations.
This incomplete validation creates a time-of-check-to-time-of-use (TOCTOU) gap where the path appears safe during initial validation but resolves to an unauthorized location during actual file operations.
Attack Vector
The attack requires a malicious rsync server to which a client connects using the --safe-links option. The attack flow involves the malicious server sending crafted file listings that include specially constructed symbolic links. These symlinks are designed to pass the client's initial validation but ultimately point to locations outside the synchronization directory.
When the client processes these symlinks, it follows the chain of links and writes files to the attacker-specified location. This could be exploited to overwrite critical system files, inject malicious scripts, or compromise application configurations. The network-based attack vector means no local access is required—an attacker need only convince or trick a user into synchronizing with the malicious server.
Detection Methods for CVE-2024-12088
Indicators of Compromise
- Unexpected files appearing outside rsync synchronization directories
- Unusual symbolic link chains pointing to sensitive system locations such as /etc, /root, or application directories
- Rsync client logs showing file writes to paths that should not be part of the sync operation
- Presence of files with modification times matching rsync synchronization events in unexpected locations
Detection Strategies
- Monitor file system changes in directories outside configured rsync target paths during and after rsync operations
- Implement file integrity monitoring (FIM) on critical system directories to detect unauthorized modifications
- Analyze rsync command-line arguments in process logs for connections to untrusted or unknown servers
- Deploy endpoint detection rules to alert on rsync processes writing to sensitive system paths
Monitoring Recommendations
- Enable detailed logging for rsync operations including source server and target paths
- Configure security information and event management (SIEM) alerts for rsync connections to non-whitelisted servers
- Implement network monitoring to detect rsync traffic to suspicious or previously unknown destinations
- Review rsync configuration files periodically to ensure --safe-links is combined with other protective measures
How to Mitigate CVE-2024-12088
Immediate Actions Required
- Update rsync to the latest patched version available from your distribution's package repository
- Avoid using rsync to synchronize with untrusted or unknown servers until patches are applied
- Review recent rsync synchronization logs for signs of exploitation or suspicious symbolic link handling
- Consider temporarily disabling automated rsync jobs that connect to external servers
Patch Information
Multiple Linux distributions have released security updates to address this vulnerability. Red Hat has published security advisories RHSA-2025:2600, RHSA-2025:7050, and RHSA-2025:8385 with patched packages for affected Enterprise Linux versions. Debian has addressed this issue in their LTS security announcement. NetApp has also released advisory NTAP-20250131-0002 for affected products. Additional technical details are available in the CERT Vulnerability Note VU#952657 and the GitHub Security Advisory.
Workarounds
- Restrict rsync connections to trusted, authenticated servers only using SSH transport with key-based authentication
- Implement network-level controls to limit outbound rsync connections to approved server addresses
- Use the --munge-links option as an additional layer of symlink protection where applicable
- Run rsync operations in isolated environments or containers to limit the impact of potential exploitation
- Deploy mandatory access control policies (SELinux, AppArmor) to restrict rsync write permissions to authorized directories only
# Example: Restrict rsync to trusted server with SSH transport
rsync -avz --safe-links -e "ssh -o StrictHostKeyChecking=yes" \
trusted-server:/data/ /local/backup/
# Verify rsync version to ensure patches are applied
rsync --version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

