RHSA-2026:82759HighCVSS 8.8

Red Hat Security Advisory: Red Hat AI Base Images 3.2.5 (CPU)

Published
October 14, 2026
Last Modified
October 26, 2026

🔗 CVE IDs covered (8)

CVE-2026-55653 →CVE-2026-55655 →CVE-2026-59995 →CVE-2026-59996 →CVE-2026-59999 →CVE-2026-60001 →CVE-2026-8461 →CVE-2026-40962 →

📋 Description

CVE-2026-8461 — ffmpeg: FFmpeg: Remote code execution via out-of-bounds write in MagicYUV decoder CVE-2026-40962 — FFmpeg: FFmpeg: Integer overflow and out-of-bounds write via CENC subsample data CVE-2026-55653 — openssh: Double free in Red Hat Enterprise Linux versions of OpenSSH DH-GEX client path during FIPS known-group validation leads to client-side denial of service CVE-2026-55655 — openssh: Local MITM of X11 forwarding via abstract UNIX socket pre-binding in Red Hat Enterprise Linux OpenSSH client versions CVE-2026-59995 — openssh: OpenSSH: sftp client allows attacker to control downloaded file location CVE-2026-59996 — openssh: OpenSSH: scp file misplacement vulnerability during remote copy CVE-2026-59999 — openssh: OpenSSH sshd: Security bypass due to incorrect handling of forwarding and tunneling options CVE-2026-60001 — openssh: OpenSSH: Brute-force attacks facilitated due to insufficient authentication delay

🎯 Affected products5

  • Red Hat OpenShift AI 3.2
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:1f19e128ac2ce3680223432f792a0bf72a6954dc24313d8bf79c48d5fbeaa740_amd64 as a component of Red Hat OpenShift AI 3.2
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:3261d67508af7dc47e38363e1d62f4e3337d771c410b9ddc3346e7b84243ee8d_s390x as a component of Red Hat OpenShift AI 3.2
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:6b7621f5575d7c25374a3da02db3a1d23f245e7e62fee9af6199d7377e243c48_ppc64le as a component of Red Hat OpenShift AI 3.2
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:6e3f91f5603a9105ff78d627aee228d68e959fd29b6923c1cc232e98e3bf8f4c_arm64 as a component of Red Hat OpenShift AI 3.2

✅ Remediation

For more information visit https://access.redhat.com/errata/RHSA-2026:82759 Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To mitigate this issue, OpenSSH clients operating in FIPS mode should avoid negotiating the `diffie-hellman-group-exchange-sha256` key exchange algorithm. This can be achieved by explicitly listing allowed key exchange algorithms in the client's SSH configuration file (e.g., `/etc/ssh/ssh_config` or `~/.ssh/config`), ensuring `diffie-hellman-group-exchange-sha256` is *not* included. For example, to use a subset of common algorithms, you might configure: ``` KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 ``` (Note: The above example `KexAlgorithms` list is illustrative and should be adjusted based on your environment's security requirements.) Additionally, avoid using non-fatal client flows, such as `ssh-keyscan`, against untrusted SSH servers while FIPS mode is enabled. Changes to `ssh_config` will take effect for new SSH connections. Workaround: To mitigate this issue, disable X11 forwarding on OpenSSH clients when it is not required. This can be achieved by avoiding the use of `-X` or `-Y` options when invoking `ssh`, or by setting `ForwardX11 no` in the SSH client configuration file (`~/.ssh/config` or `/etc/ssh/ssh_config`). Disabling X11 forwarding will prevent the client from attempting to establish X11 connections, thereby removing the attack vector. Workaround: To mitigate this issue, avoid using the `sftp server:/path .` command when connecting to untrusted or potentially malicious SFTP servers. Exercise caution and verify the authenticity of SFTP servers before initiating file transfers, especially when using commands that implicitly define the download destination, and also avoid running SFTP sessions with elevated privileges (such as root). Workaround: To mitigate this issue, users should avoid performing `scp` operations directly between two remote destinations. Instead, consider copying files from the first remote host to a local machine, and then from the local machine to the second remote host. Alternatively, use `sftp` or `rsync` for remote file transfers, as these utilities are not affected by this specific vulnerability. Workaround: To mitigate this issue, if `DisableForwarding=yes` is set in `/etc/ssh/sshd_config` to prevent all forwarding, ensure that `PermitTunnel` is explicitly set to `no` in the same configuration file. This will enforce the intended security policy. After modifying `/etc/ssh/sshd_config`, restart the `sshd` service for the changes to take effect. This may temporarily interrupt active SSH sessions.

🔗 References (12)