RHSA-2026:67462HighCVSS 8.2

Red Hat Security Advisory: rsync security, bug fix, and enhancement update

Published
September 14, 2026
Last Modified
September 14, 2026

🔗 CVE IDs covered (20)

CVE-2026-53783 →CVE-2026-53784 →CVE-2026-53789 →CVE-2026-53795 →CVE-2026-53802 →CVE-2026-70452 →CVE-2026-70457 →CVE-2026-53785 →CVE-2026-53803 →CVE-2026-70453 →CVE-2026-70458 →CVE-2026-70463 →CVE-2026-70454 →CVE-2026-70456 →CVE-2026-53791 →CVE-2026-53793 →CVE-2026-70464 →CVE-2026-53790 →CVE-2026-70460 →CVE-2026-70461 →

📋 Description

CVE-2026-53783 — rsync: rsync: Directory escape via TOCTOU race condition in rrsync CVE-2026-53784 — rsync: rsync: Unauthorized File Access via Symlink Module Root CVE-2026-53785 — rsync: rsync: Arbitrary file write via path traversal in --relative mode CVE-2026-53789 — rsync: rsync: Arbitrary file deletion via malicious file list CVE-2026-53790 — rsync: rsync < 3.5.0 Command Injection via Multiple Code Paths CVE-2026-53791 — rsync: rsync < 3.5.0 Daemon IP Spoofing via PROXY Protocol Header CVE-2026-53793 — rsync: rsync < 3.5.0 Path Confinement Bypass via /./ Boundary Marker in Chroot Mode CVE-2026-53795 — rsync: rsync: Arbitrary file write via --temp-dir or --link-dest options CVE-2026-53802 — rsync: rsync: Arbitrary File Read via Symlink Following CVE-2026-53803 — rsync: rsync: Local Privilege Escalation via Symlink Following CVE-2026-70452 — rsync: rsync 3.1.0 < 3.5.0 Access Control Bypass via DNS Resolution Failure CVE-2026-70453 — rsync: rsync: Denial of Service via Algorithmic Complexity CVE-2026-70454 — rsync: rsync: TLS Certificate Validation Bypass allows interception of encrypted sessions CVE-2026-70456 — rsync: rsync: Heap Out-of-Bounds Write via crafted argument list CVE-2026-70457 — rsync: rsync: Memory corruption via out-of-bounds write in size parsing CVE-2026-70458 — rsync: rsync: Memory corruption via crafted file entries CVE-2026-70460 — rsync: rsync 2.3.3 < 3.5.0 Path Traversal via --partial-dir/--backup-dir Symlink CVE-2026-70461 — rsync: rsync: Information disclosure and denial of service via crafted files-from entry CVE-2026-70463 — rsync: rsync: Authorization bypass via auth users directive parsing CVE-2026-70464 — rsync: rsync: Denial of Service via handshake stall

🎯 Affected products17

  • Red Hat Enterprise Linux AppStream (v. 9)
  • Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-0:3.2.7-1.el9_8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-0:3.2.7-1.el9_8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-0:3.2.7-1.el9_8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-0:3.2.7-1.el9_8.src as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-0:3.2.7-1.el9_8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-daemon-0:3.2.7-1.el9_8.noarch as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • rsync-debuginfo-0:3.2.7-1.el9_8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debuginfo-0:3.2.7-1.el9_8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debuginfo-0:3.2.7-1.el9_8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debuginfo-0:3.2.7-1.el9_8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debugsource-0:3.2.7-1.el9_8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debugsource-0:3.2.7-1.el9_8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debugsource-0:3.2.7-1.el9_8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-debugsource-0:3.2.7-1.el9_8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 9)
  • rsync-rrsync-0:3.2.7-1.el9_8.noarch as a component of Red Hat Enterprise Linux AppStream (v. 9)

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Workaround: Do not use the rrsync SSH forced-command wrapper until patched packages are applied. If restricted rsync over SSH is strictly required, grant access only to SSH identities that are fully trusted with the host account's entire filesystem privileges, as rrsync cannot safely enforce directory boundaries. Note that standard rsync daemon firewall controls (TCP 873) do not mitigate this flaw, as execution occurs entirely over SSH (TCP 22). Workaround: To mitigate this vulnerability, ensure that the `use chroot` option is enabled in the rsync daemon configuration. If `use chroot` cannot be enabled, avoid using symlinks as the module root path or any of its components in the rsync daemon configuration. After modifying the rsync configuration, restart the rsync service for the changes to take effect. Workaround: To mitigate this issue, avoid using the rsync --relative (-R) option when synchronizing with untrusted senders. Because kernel-level symlink protections cannot prevent rsync from following malicious destination-tree symlinks created by the same executing user, strict sender verification is required. Restricting --relative operations to fully trusted sources prevents attackers from exploiting implied relative paths to achieve path traversal. Workaround: To reduce the risk of arbitrary file deletion, ensure that rsync operations using the `--delete` option are only performed with trusted remote sources. If rsync is configured as a daemon (`rsyncd`), restrict network access to the rsync service (port 873/tcp) to only trusted clients using firewall rules. For example, using `firewall-cmd` on Red Hat Enterprise Linux: `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_ADDRESS>" port port="873" protocol="tcp" accept'` `firewall-cmd --reload` This may impact legitimate rsync operations from untrusted networks. A service reload or restart may be required for changes to take effect. Workaround: Do not set RSYNC_CONNECT_PROG or pass untrusted hostnames/paths into rsync / rsync-ssl. If rsyncd is required, omit pre-xfer/post-xfer/early exec unless the command ignores client-controlled RSYNC_* values, and restrict TCP/873 to trusted clients Workaround: Restrict rsync daemon TCP/873 to the trusted proxy only (CME-202). If PROXY protocol is unused, leave proxy protocol disabled (the default). Workaround: To mitigate this issue, avoid configuring rsync modules with a /./ boundary marker in their root path when operating in chroot mode. Review existing rsync configurations to ensure that module root paths do not contain /./ when chroot is enabled. If chroot mode is not strictly required for a given rsync module, consider disabling it. If changes are made to the rsync configuration, a restart of the rsync service may be required for the changes to take effect. Workaround: Do not pass untrusted values into --temp-dir or --link-dest. If you need those options, keep the destination (and those dirs) free of writes by untrusted users so a parent cannot be swapped to a symlink. Do not use --partial-dir or --inplace when pulling from an untrusted server. If rsyncd runs with use chroot = no, restrict who can connect. Workaround: Ensure the rsync daemon runs with the principle of least privilege, enabling use chroot = yes to securely jail the process to its module tree. Restrict write access for daemon configuration directories and files specified by --files-from or --password-file to trusted administrators only. When running rsync outside of daemon mode, ensure users only process input files originating from trusted, non-world-writable directories. Workaround: Do not run rsync setuid or point output paths (--log-file, --write-batch, or daemon config/log files) to user-writable directories like /tmp. While fs.protected_symlinks=1 prevents simple symlink creation in sticky directories on RHEL 7+, it does not stop parent-component attacks in standard directories. If the rsyncd daemon is unneeded, disable it (systemctl disable --now rsyncd); if required, enforce least-privilege execution and restrict network access to trusted hosts. Workaround: To mitigate this issue, configure rsync to use IP-based access controls instead of hostname-based rules in `rsyncd.conf`. Alternatively, restrict network access to the rsync daemon using firewall rules to allow connections only from trusted IP addresses or networks. This limits exposure by preventing untrusted remote attackers from reaching the service and attempting to induce DNS resolution failures. If changes are made to `rsyncd.conf`, the rsync daemon may need to be restarted or reloaded for the changes to take effect. Workaround: Disable unused rsyncd services (systemctl disable --now rsyncd), or restrict daemon access to trusted clients via hosts allow and firewall rules. Avoid synchronizing with untrusted senders or pushing to untrusted receivers and upload modules to prevent processing malicious file lists. To contain potential Denial of Service, enforce CPU resource limits on rsync processes using systemd cgroups or ulimit -t to prevent a quadratic search walk from starving the host. Workaround: Do not use rsync-ssl with the openssl or stunnel backends. Use rsync over SSH, which authenticates the host and encrypts the session: rsync -avz -e ssh /source user@remote:/destination. If daemon TLS cannot be avoided, restrict those sessions to trusted networks Workaround: To mitigate this issue, restrict network access to rsync services to trusted hosts and networks using firewall rules. If rsync is used in daemon mode, configure `rsyncd.conf` to limit access. When using rsync as a client, avoid synchronizing with untrusted rsync servers. Workaround: If rsync is configured to run as a daemon, restrict network access to trusted hosts using firewall rules. For example, to limit access to localhost: `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="873" protocol="tcp" source address="127.0.0.1" accept'` `firewall-cmd --reload` This may impact legitimate remote rsync operations. If rsync is not used as a daemon, ensure that only trusted sources are used for rsync operations. Workaround: Disable the rsyncd daemon if unused (systemctl disable --now rsyncd), or strictly limit TCP/873 access to trusted clients via firewall rules. For daemons that must remain active, explicitly set refuse options = checksum in rsyncd.conf to block the demonstrated out-of-bounds write vector. Finally, when operating as a client pulling from untrusted peers, always append the --hard-links (-H) flag to force safe memory allocation and prevent corruption. Workaround: Disable the rsyncd daemon if it is unused (systemctl disable --now rsyncd), or strictly limit TCP/873 access to trusted clients via firewall rules. Within rsyncd.conf, block the exploit vectors directly by setting refuse options = partial-dir backup-dir and maintain defense-in-depth by enforcing use chroot = yes. Finally, ensure no root- or daemon-owned symlinks point outside your module paths, and avoid using the vulnerable flags when operating as a client against untrusted sources. Workaround: Restrict access to the rsync daemon (TCP 873) to trusted hosts with firewall rules. If the daemon is unused, disable and stop rsyncd.service. Workaround: To prevent this authorization bypass, ensure that no group names containing spaces are used within the `auth users` directive in the `rsyncd.conf` configuration file. Review and update any existing configurations to remove spaces from group names in this directive. After making changes, restart the `rsync` service for the new configuration to take effect. For example, use `systemctl restart rsyncd` if managing the service with systemd. Note that restarting the service will temporarily interrupt active rsync operations. Work…

🔗 References (20)