RHSA-2026:37382HighCVSS 7.7

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

Published
July 9, 2026
Last Modified
August 25, 2026

🔗 CVE IDs covered (8)

CVE-2026-60002 →CVE-2026-59995 →CVE-2026-59996 →CVE-2026-59997 →CVE-2026-59998 →CVE-2026-59999 →CVE-2026-60000 →CVE-2026-60001 →

📋 Description

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-59997 — openssh: OpenSSH: SFTP security bypass due to command-line argument parsing flaw CVE-2026-59998 — openssh: OpenSSH: Undocumented GSSAPIStrictAcceptorCheck behavior impacts security in Windows Active Directory CVE-2026-59999 — openssh: OpenSSH sshd: Security bypass due to incorrect handling of forwarding and tunneling options CVE-2026-60000 — openssh: OpenSSH: Denial of Service via excessive GSSAPI authentication attempts CVE-2026-60001 — openssh: OpenSSH: Brute-force attacks facilitated due to insufficient authentication delay CVE-2026-60002 — openssh: OpenSSH: Use-after-free vulnerability during host key re-exchange on the client side

🎯 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, 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, ensure that all security-relevant command-line arguments for the `internal-sftp` server are positioned within the first nine arguments. Alternatively, consider using the default SFTP server implementation if custom configurations relying on numerous arguments are not strictly necessary. If `internal-sftp` is used with more than nine arguments, verify that no critical security options are being silently discarded. Workaround: To mitigate this issue, avoid using GSSAPI authentication for `sshd` when the server is integrated with a Windows Active Directory environment. If GSSAPI authentication is not strictly required, it can be disabled by setting `GSSAPIAuthentication no` in the `/etc/ssh/sshd_config` file. After modifying the configuration, the `sshd` service must be restarted for the changes to take effect. Note that restarting the `sshd` service will terminate all active SSH sessions. ```bash # echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config # systemctl restart sshd ``` Alternatively, if GSSAPI authentication is necessary in such an environment, ensure that the network path between the client and the `sshd` server, and to the Active Directory, is secured and trusted to prevent man-in-the-middle attacks. 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. Workaround: To mitigate this issue, OpenSSH clients should only connect to trusted SSH servers. Enforcing strict host key checking and carefully managing `known_hosts` files can help prevent connections to servers with unexpected or altered host keys, thereby reducing exposure to this client-side vulnerability.

🔗 References (12)