Skip to content

GHSA-6692-28cx-wpqq on CTRL-OS 26.05

Aliases: GHSA-6692-28cx-wpqq, CVE-2026-70452

Packages: rsync

Status: Plausible

Advisory Information

match_hostname() performs a forward DNS lookup of a hostname token written in hosts allow / hosts deny and compares the result against the connecting IP. When that lookup FAILED it returned "no match" -- indistinguishable from a genuine non-match -- so allow_access() fell through and ADMITTED the connection. A daemon configured hosts deny = <hostname> therefore silently accepted the very host it was configured to block.

No attacker DNS control is required. Two ordinary situations produce it:

  • a transient resolver failure, and
  • a daemon chroot whose tree lacks resolver configuration. Note this is the GLOBAL daemon chroot, entered before module selection, not a per-module use chroot: module access checking runs before the per-module chroot, so a resolver-less module chroot does not trigger this. rsyncd.conf(5) does warn that a daemon chroot may need OS and library files present; an administrator who does not supply resolver configuration silently loses the deny rule.

forward lookup is enabled by default, so a default daemon that uses hostname tokens in hosts deny is affected.

Fixed by treating an unresolvable token on a DENY list as a match (deny). Allow-list tokens keep failing as a non-match, so a resolver failure cannot grant access through an allow rule either.

The regression drives the fail-open path with a permanently unresolvable .invalid token; it establishes the behaviour, not a transiently unreachable real hostname.

This is the sibling of CVE-2026-43617, which fixed only the reverse-lookup path in the same function; the forward-lookup path was left failing open.

Affected: 3.1.0 through 3.4.4 with forward lookup enabled, which is the DEFAULT (forward lookup of hostname tokens entered in 3.1.0)

Fixed in: 3.5.0

Reporter: Leonid Bugaev (security audit); sibling of CVE-2026-43617

Test: daemon-deny-dns-failopen

Updates

2026-08-14 16:57 CEST

Metadata changes:

  • Status for package rsync: “Plausible”

2026-08-14 16:55 CEST

Metadata changes:

  • Status for package rsync: “New”