CVE-2026-55653

What it actually does

This vulnerability is a client-side memory-management flaw in OpenSSH's Diffie-Hellman Group Exchange (DH-GEX) key-exchange handling. When an OpenSSH client operating in FIPS mode connects to a malicious or compromised SSH server, the server can send crafted DH-GEX group parameters that trigger a double free during known-group validation. The practical result is termination of the SSH client process. Based on the provided details, the impact is limited to availability of the client session; it does not indicate remote code execution, credential theft, or server-side compromise.

Why it matters to the business

An attacker who can lure users, automation, or administrative tooling into connecting to a malicious SSH server can cause SSH client sessions to crash, disrupting administration, automation, deployments, backups, file transfers, or operational workflows that depend on OpenSSH clients. The risk is most relevant to environments using OpenSSH in FIPS mode, including hardened Linux images and enterprise platforms. Although the CVSS and EPSS values indicate relatively low severity and low observed exploitation likelihood, disruption can still matter where SSH is part of critical operational processes.

How an attack unfolds

An attacker sets up or compromises an SSH server and waits for a vulnerable OpenSSH client to connect. The victim must initiate the SSH connection, which may occur through manual administration, scripts, CI/CD jobs, configuration management, monitoring, or file-transfer workflows. During SSH negotiation, the malicious server selects or influences the DH-GEX key-exchange path and returns attacker-controlled group parameters. In FIPS mode, the client performs known-group validation on those parameters. The crafted response causes the client to free the same memory twice, leading the operating system or allocator to terminate the SSH process. The attacker achieves denial of service for that client connection, typically visible as a failed SSH session, aborted process, segmentation fault, or core dump.

How to fix it

Apply OpenSSH updates from the relevant operating-system or platform vendor as soon as fixed packages are available. No exact fixed versions were provided in the input, so track advisories for OpenSSH, Red Hat Enterprise Linux, Red Hat hardened images, and Red Hat OpenShift Container Platform. As a mitigation, reduce or disable use of DH-GEX key-exchange algorithms on clients where operationally feasible by removing algorithms such as diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256 from client SSH configuration. Prefer modern key-exchange algorithms such as curve25519 or vendor-approved FIPS-compatible alternatives where policy allows. Enforce strict host-key verification to reduce the chance of connecting to malicious or impersonated SSH servers. Limit automation and administrative clients to known SSH endpoints, avoid connecting to untrusted SSH servers, and review FIPS-mode systems as a priority because the vulnerable path is tied to FIPS known-group validation.

How to confirm the fix worked

Confirm installed OpenSSH client package versions against the relevant vendor advisory once fixed builds are released. Validate that client SSH configuration does not offer DH-GEX algorithms if mitigation is used; for example, review ssh_config, included configuration snippets, and effective client algorithm lists. Test SSH connections to known-good servers after remediation to confirm normal operation. Where feasible, perform a controlled connection test against a benign SSH server configured to negotiate allowed key-exchange algorithms and verify that DH-GEX is not selected. Confirm that FIPS-mode systems have received the vendor fix or have compensating configuration controls. Review package-management output, container base-image rebuild dates, and platform node image versions for Red Hat Enterprise Linux, Red Hat hardened images, and OpenShift environments.

Typical attack path

1. Attacker deploys, compromises, or impersonates an SSH server reachable by the victim client.
2. Victim user, script, or automation initiates an SSH connection to the attacker-controlled server.
3. SSH negotiation enters the Diffie-Hellman Group Exchange client path.
4. The malicious server returns crafted DH-GEX group parameters.
5. The OpenSSH client, running in FIPS mode, performs known-group validation on attacker-controlled parameters.
6. The validation path triggers a double free in the client process.
7. The SSH client process terminates, causing the session or dependent automation to fail.

How to detect it

Detection should focus on evidence that OpenSSH clients crashed after initiating outbound SSH connections, especially from FIPS-mode systems. Review system logs, journald, syslog, audit logs, endpoint telemetry, EDR crash events, automation job logs, CI/CD runner logs, and core-dump records for ssh process termination. Look for allocator messages indicating a double free, segmentation faults, abnormal process exits, or systemd-coredump entries involving /usr/bin/ssh or related OpenSSH client binaries. Correlate crash timestamps with outbound TCP connections to port 22, recent host-key prompts or host-key changes, first-time SSH connections, failed deployment/configuration-management jobs, or connections to untrusted SSH servers. Where network telemetry is available, identify SSH sessions that negotiated Diffie-Hellman Group Exchange or attempted DH-GEX key exchange immediately before client termination. There are no known public exploit-specific payload strings from the provided information, so detection should be behavior-based and crash-focused rather than signature-only.

• free(): double free detected
• double free or corruption
• malloc(): unaligned tcache chunk detected
• segfault at
• comm="ssh"
• exe="/usr/bin/ssh"
• systemd-coredump
• Process ssh
• /usr/bin/ssh
• /var/lib/systemd/coredump
• diffie-hellman-group-exchange-sha1
• diffie-hellman-group-exchange-sha256
• kex_exchange_identification
• Connection closed by remote host

What your security team should do

• Inventory systems, images, containers, and automation runners that use OpenSSH clients in FIPS mode.
• Monitor vendor advisories and patch OpenSSH packages as soon as fixed versions are available for affected platforms.
• Where patching is not yet available, disable DH-GEX key-exchange algorithms on OpenSSH clients if compatible with security policy and operational requirements.
• Restrict SSH automation to known, trusted hosts and require strict host-key checking to reduce exposure to malicious SSH servers.
• Prioritize validation for hardened images, administrative workstations, CI/CD runners, backup systems, configuration-management systems, and OpenShift/RHEL infrastructure that initiate outbound SSH connections.
• Search recent logs for SSH client crashes, segmentation faults, allocator double-free messages, and systemd-coredump entries involving ssh.
• Review failed automation or operational jobs that coincide with outbound SSH connections to unfamiliar or newly changed hosts.
• Because this issue is not currently listed in KEV and EPSS is low, handle it as a targeted availability risk rather than an internet-wide emergency, while still applying vendor fixes promptly.