CLSA-2026-1789786148
See a problem?- Import Source
- https://github.com/cloudlinux/tuxcare-osv/tree/main/data/els_os/almalinux9.2esu/CLSA-2026-1789786148.json
- JSON Data
- https://api.osv.dev/v1/vulns/CLSA-2026-1789786148
- Upstream
- Published
- 2026-10-08T18:36:31Z
- Modified
- 2026-10-26T09:30:50Z
- Summary
- rsync: Fix of 4 CVEs
- Details
-
- CVE-2026-53793: confine a daemon module whose path carries a "/./" inner boundary marker to the inner module root rather than only to the kernel chroot, by widening the single predicate every confined wrapper, the secure symlink handling and the directory scan test, so a symlink inside the module can no longer reach a sibling that is inside the chroot but outside the module; also sanitize the peer-supplied basis name on the client
- CVE-2026-70454: require CA verification for the gnutls and stunnel backends of the rsync-ssl helper and bind the server certificate to the requested host, so an on-path attacker can no longer present a certificate valid for another name; validate the hostname before it reaches the TLS client
- CVE-2026-70464: bound the peer-driven daemon handshake with an absolute deadline armed before any peer input is read, so an unauthenticated client can no longer hold a connection slot open past "max connections" by stalling the greeting or trickling arguments
- NOTE, behaviour change from the CVE-2026-70454 fix: rsync-ssl is now fail-closed for the backends that could not verify at all. With RSYNC_SSL_TYPE=gnutls or stunnel and RSYNC_SSL_CA_CERT unset the helper exits 1 instead of connecting without verification; set RSYNC_SSL_ALLOW_INSECURE_GNUTLS=1 or RSYNC_SSL_ALLOW_INSECURE_STUNNEL=1 to restore the old behaviour, and RSYNC_SSL_SKIP_HOSTNAME_CHECK=1 to keep CA verification without the hostname binding. The default openssl path is unchanged: it already verified, and still does
- References
Affected packages
TuxCare:AlmaLinux:9.2 / rsync
Package
- Name
- rsync
- Purl
- pkg:rpm/tuxcare/rsync?distro=almalinux-9.2