CVE-2026-44509 in rsync
Summary
by MITRE • 07/21/2026
Rsync is a file-copying tool that uses a delta-transfer algorithm to synchronize remote and local files. In versions prior to 3.4.3, previous bug fixes for symlink races in open() calls missed races in other path based system calls like chmod() and chown(). For rsync daemons with "use chroot = no" this allows an attacker with local filesystem access to change permissions, ownership or timestamp on a file outside the exported module. This issue is fixed in version 3.4.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in rsync versions prior to 3.4.3 represents a critical race condition affecting symbolic link handling during file permission and ownership modifications. This flaw specifically impacts systems where the rsync daemon operates with "use chroot = no" configuration, creating an exploitable path traversal scenario that allows local attackers to manipulate files outside their intended module boundaries. The vulnerability stems from incomplete bug fixes that addressed symlink races in open() calls but failed to account for similar race conditions present in other system calls such as chmod() and chown(). These functions, which are essential for file system operations within rsync's synchronization process, create opportunities for attackers to exploit time-of-check to time-of-use vulnerabilities.
The technical implementation of this vulnerability leverages the fundamental design flaw in how rsync handles symbolic link resolution during permission changes. When a daemon processes file operations without chroot isolation, it can be tricked into following symbolic links that point outside the configured module paths. This race condition occurs because rsync performs path validation checks at one point in time and then executes system calls that may operate on different targets if the symbolic links have been altered between the check and execution phases. The flaw specifically affects scenarios where an attacker has local access to the filesystem and can manipulate symbolic link targets, enabling them to perform unauthorized chmod() and chown() operations against files located outside the restricted module directories.
The operational impact of this vulnerability extends beyond simple privilege escalation as it enables attackers to modify critical system files, change ownership of sensitive data, or alter file timestamps in ways that could compromise system integrity. The lack of chroot isolation means that attackers can target any file accessible through the daemon's process context, potentially allowing them to modify system configuration files, overwrite binaries, or manipulate log files to cover their tracks. This vulnerability particularly affects enterprise environments where rsync daemons are commonly configured for network file synchronization without proper chroot restrictions, creating potential attack vectors for both internal and external adversaries.
Mitigation strategies should focus on immediate version upgrades to rsync 3.4.3 or later releases that contain the complete fix for this race condition. Organizations must also review their rsync daemon configurations to ensure that "use chroot = yes" is properly implemented wherever possible, providing additional isolation layers that prevent path traversal attacks. System administrators should conduct thorough audits of existing rsync configurations to identify all instances where chroot isolation is disabled and implement proper access controls. The vulnerability aligns with CWE-367, which addresses Time-of-Check to Time-of-Use race conditions, and represents a specific ATT&CK technique under TA0004 (Privilege Escalation) related to file system permissions manipulation. Additional protective measures include implementing proper monitoring of rsync daemon activities and establishing automated checks for unauthorized symlink modifications in critical system directories, ensuring that any changes to symbolic link targets are properly logged and validated before being processed by the synchronization service.