RHSA-2026:36759MediumCVSS 5.0

Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Published
July 8, 2026
Last Modified
September 7, 2026

🔗 CVE IDs covered (3)

CVE-2026-55653 →CVE-2026-55654 →CVE-2026-55655 →

📋 Description

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-55654 — openssh: Heap out-of-bounds read in Red Hat Enterprise Linux versions of OpenSSH GSSAPI indicator cleanup due to missing NULL sentinel termination CVE-2026-55655 — openssh: Local MITM of X11 forwarding via abstract UNIX socket pre-binding in Red Hat Enterprise Linux OpenSSH client versions

🎯 Affected products4

  • Red Hat Hardened Images
  • openssh-main@aarch64 as a component of Red Hat Hardened Images
  • openssh-main@src as a component of Red Hat Hardened Images
  • openssh-main@x86_64 as a component of Red Hat Hardened Images

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://images.redhat.com/ 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.

🔗 References (7)