CVE-2026-43619: Rsync Symlink Race Condition Vulnerability

CVE-2026-43619 Overview

CVE-2026-43619 affects Rsync version 3.4.2 and prior. The vulnerability is a symlink race condition [CWE-59] in path-based system calls including chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir, and lstat. Local attackers with filesystem access on an rsync daemon configured with use chroot = no can exploit the timing window between path resolution and syscall execution. By swapping symlinks during this window, attackers redirect operations to files outside the exported rsync module boundary.

Critical Impact

Local attackers can apply sender-supplied permissions, ownership, timestamps, or filenames to arbitrary files outside the intended rsync module, breaking module isolation on daemons running without chroot.

Affected Products

• Rsync version 3.4.2 and earlier
• Rsync daemons configured with use chroot = no
• Systems exposing rsync modules to local users

Discovery Timeline

• 2026-05-20 - CVE-2026-43619 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-43619

Vulnerability Analysis

The vulnerability is a time-of-check to time-of-use (TOCTOU) flaw in rsync's handling of path-based system calls within exported modules. When rsync resolves a target path and subsequently invokes syscalls such as chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir, or lstat, an attacker can replace a path component with a symlink between resolution and syscall execution. The redirected syscall then operates on a target chosen by the attacker rather than the intended file inside the module.

Exploitation requires local filesystem access and the ability to win a narrow race window. Successful exploitation lets the attacker apply sender-controlled attributes — permissions, ownership, timestamps, or filenames — to arbitrary files reachable by the rsync daemon process.

Root Cause

The root cause is that rsync uses path-based syscalls rather than file-descriptor-relative variants such as fchmodat, unlinkat, or renameat with AT_SYMLINK_NOFOLLOW. Path-based syscalls re-resolve every component on each call. When use chroot = no is configured, the daemon does not isolate the module root via chroot(), so symlinks placed inside the module can resolve to filesystem locations outside it.

Attack Vector

The attack vector is local. An authenticated local user with write access to a path traversed by an rsync operation creates a benign file or directory, waits for rsync to resolve the path, then replaces the component with a symlink pointing outside the module. If the swap lands inside the race window, the subsequent syscall is redirected. Refer to the GitHub Security Advisory GHSA-4h9m-w5ff-j735 and the VulnCheck Symlink Race Condition Advisory for technical details.

Detection Methods for CVE-2026-43619

Indicators of Compromise

• Unexpected ownership, permission, or timestamp changes on files outside configured rsync module paths.
• Creation or deletion of symlinks within rsync module directories during active transfers.
• Rsync daemon log entries showing transfers immediately preceding attribute changes on unrelated system files.

Detection Strategies

• Audit rsync daemon configurations for any module with use chroot = no and treat them as in-scope for monitoring.
• Deploy filesystem auditing such as auditd rules on chmod, chown, rename, unlink, and symlink syscalls invoked by the rsync daemon process.
• Correlate rsync session timestamps with filesystem attribute changes on paths outside exported modules.

Monitoring Recommendations

• Monitor process-level activity for rsync daemons making syscalls that resolve outside their configured module roots.
• Alert on rapid symlink creation and deletion sequences within rsync-served directories, which indicate race-condition exploitation attempts.
• Track rsync version inventories across hosts to identify systems still running 3.4.2 or earlier.

How to Mitigate CVE-2026-43619

Immediate Actions Required

• Upgrade rsync to version 3.4.3 or later, available from the Rsync GitHub Release v3.4.3.
• Set use chroot = yes on all rsync daemon modules where chroot is operationally feasible.
• Restrict local shell access on hosts running rsync daemons to trusted administrators only.

Patch Information

The rsync project released version 3.4.3 to address CVE-2026-43619. The fix is published in the GitHub Security Advisory GHSA-4h9m-w5ff-j735. Administrators should apply distribution updates as they become available or build 3.4.3 from source.

Workarounds

• Enable use chroot = yes in rsyncd.conf to confine the daemon to the module root and prevent symlink redirection outside it.
• Restrict module access to authenticated users using auth users and secrets file directives.
• Mount the filesystem hosting rsync modules with nosymfollow where supported by the kernel and filesystem.
• Run the rsync daemon under a dedicated unprivileged user account with minimal filesystem permissions.

# Configuration example: rsyncd.conf hardening
[backup]
    path = /srv/rsync/backup
    use chroot = yes
    uid = rsyncuser
    gid = rsyncgroup
    read only = no
    auth users = backupclient
    secrets file = /etc/rsyncd.secrets
    hosts allow = 10.0.0.0/24