CVE-2026-43617: Rsync Auth Bypass Vulnerability

CVE-2026-43617 Overview

CVE-2026-43617 is an authorization bypass vulnerability in the rsync daemon affecting versions 3.4.2 and prior. The flaw resides in hostname-based access control list (ACL) enforcement when the daemon is configured with chroot. When reverse DNS resolution fails, the daemon defaults the source hostname to UNKNOWN rather than rejecting the connection. Attackers who control the PTR record for their source IP can craft hostnames that evade administrator-defined hosts deny rules. The vulnerability is classified under CWE-289: Authentication Bypass by Alternate Name.

Critical Impact
Remote attackers can bypass hostname-based deny rules in rsync daemon configurations, gaining access to file shares that administrators intended to restrict.

Affected Products

Rsync daemon versions 3.4.2 and prior
Rsync deployments using hostname-based ACLs with chroot enabled
Linux and Unix systems running rsync server in daemon mode

Discovery Timeline

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

Technical Details for CVE-2026-43617

Vulnerability Analysis

The rsync daemon supports access control through hosts allow and hosts deny directives in rsyncd.conf. These rules can match either IP addresses or hostnames. When a client connects, the daemon performs a reverse DNS lookup on the client IP to determine the hostname for ACL matching.

When the daemon runs with chroot enabled, the chrooted environment lacks the resolver libraries and configuration files required for DNS lookups. The reverse DNS resolution silently fails. Rather than rejecting the connection or treating the failure as a deny condition, the daemon assigns the literal string UNKNOWN as the hostname and continues evaluating ACL rules against that placeholder.

The consequence is that any deny rule keyed on a hostname pattern, such as hosts deny = *.untrusted.example.com, will not match for connections where reverse DNS fails. Attackers who control PTR records for their IP address can exploit this by configuring records that cause resolution failures or that resolve to values not covered by deny rules.

Root Cause

The root cause is insecure default handling of failed name resolution within the chroot context. The daemon treats DNS failure as a successful lookup returning UNKNOWN rather than as an error condition that should trigger fail-closed semantics. Administrators reasonably expect hostname-based deny rules to function, but the chroot environment silently breaks this assumption.

Attack Vector

An attacker requires network reachability to the rsync daemon and control over the PTR record for their source IP address. By configuring reverse DNS to return responses that fail resolution within the chrooted daemon, the attacker forces the daemon to fall back to the UNKNOWN hostname. Connections then bypass any hosts deny patterns that would otherwise match the true hostname.

The attack complexity is elevated because exploitation requires PTR record control and a vulnerable configuration combining chroot with hostname-based ACLs. No authentication is required to attempt the bypass. For technical details, see the GitHub Security Advisory GHSA-rjfm-3w2m-jf4f and the Vulncheck Authorization Bypass Advisory.

Detection Methods for CVE-2026-43617

Indicators of Compromise

Rsync daemon log entries showing successful connections with hostname UNKNOWN where deny rules were expected to apply
Connections from source IPs whose PTR records resolve inconsistently or fail resolution
Unexpected access to rsync modules that should be restricted by hostname-based rules
Rsync daemon processes running with use chroot = yes combined with hostname patterns in hosts allow or hosts deny

Detection Strategies

Audit rsyncd.conf files for the combination of use chroot = yes and hostname-based hosts allow or hosts deny directives
Review rsync daemon logs for the literal string UNKNOWN appearing in client hostname fields
Correlate rsync access logs with authoritative DNS resolution to identify discrepancies
Monitor for rsync daemon versions 3.4.2 and prior across the environment

Monitoring Recommendations

Enable verbose rsync daemon logging with log file and transfer logging = yes to capture client hostname resolution outcomes
Forward rsync daemon logs to a centralized logging platform for hostname pattern analysis
Alert on rsync connections recording UNKNOWN as the resolved hostname
Track configuration drift on hosts running rsync in daemon mode

How to Mitigate CVE-2026-43617

Immediate Actions Required

Upgrade rsync to version 3.4.3 or later, available at the GitHub Release v3.4.3
Inventory all rsync daemon deployments and identify configurations using both chroot and hostname-based ACLs
Replace hostname-based hosts allow and hosts deny directives with IP address or CIDR-based rules where possible
Restrict network access to rsync daemon ports (873/tcp) through firewall rules

Patch Information

The rsync project released version 3.4.3 to address this vulnerability. The fix changes how the daemon handles failed reverse DNS resolution within chrooted environments. Administrators should consult their distribution's package repositories for backported fixes or install from upstream. Details are documented in the GitHub Security Advisory GHSA-rjfm-3w2m-jf4f.

Workarounds

Disable chroot by setting use chroot = no if hostname-based ACLs are required, accepting the reduced filesystem isolation tradeoff
Replace hostname patterns with IP address or subnet patterns in hosts allow and hosts deny directives
Place rsync daemons behind a reverse proxy or VPN that enforces source identity before connections reach the daemon
Require rsync over SSH transport instead of the standalone daemon for sensitive shares

bash

# Configuration example: replace hostname rules with IP-based rules in rsyncd.conf
[backup]
    path = /srv/backup
    use chroot = yes
    read only = no
    hosts allow = 10.0.0.0/8 192.168.10.0/24
    hosts deny = *