RHSA-2026:71446HighCVSS 8.2

Red Hat Security Advisory: OpenShift Container Platform 4.22.16 bug fix and security update

Published
September 29, 2026
Last Modified
October 30, 2026

🔗 CVE IDs covered (20)

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

📋 Description

CVE-2026-13221 — perl: Perl: Incorrect regular expression processing via large regular expressions 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 products5

  • Red Hat OpenShift Container Platform 4.22
  • rhcos-aarch64-4.22.9.8.202609221802-0 as a component of Red Hat OpenShift Container Platform 4.22
  • rhcos-ppc64le-4.22.9.8.202609221802-0 as a component of Red Hat OpenShift Container Platform 4.22
  • rhcos-s390x-4.22.9.8.202609221802-0 as a component of Red Hat OpenShift Container Platform 4.22
  • rhcos-x86_64-4.22.9.8.202609221802-0 as a component of Red Hat OpenShift Container Platform 4.22

✅ Remediation

For OpenShift Container Platform 4.22 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/release_notes/ You may download the oc tool and use it to inspect release image metadata for x86_64, s390x, ppc64le, and aarch64 architectures. The image digests may be found at https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags. The sha values for the release are as follows: (For x86_64 architecture) The image digest is sha256:55a0c0c8f9a285fa468009511dd878d5492436ceb4f0207933b6403d19353876 (For s390x architecture) The image digest is sha256:f45ad2f2c1d8a45f339a69879d6baa5f4e5ba0c922147bf75f8451fa4cf38847 (For ppc64le architecture) The image digest is sha256:f29efc92dccdd9133824f9f083576c900ca7800bb331095581144d1b982e37d2 (For aarch64 architecture) The image digest is sha256:dfebff37094c5a2921e1c4070878293727c48e6dc6754a88bd7bab91f0a3b869 All OpenShift Container Platform 4.22 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html-single/updating_clusters/index#updating-cluster-cli. 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 …

🔗 References (23)