CVE-2024-6387: OpenSSH sshd signal handler race condition allows unauthenticated remote code execution

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 17 September 2026. Confidence: high.

high priorityCVSS 8.1 with network reachability, no authentication, and high EPSS plus public exploit references make this a high-priority patching target despite the high attack complexity.

What it is

A security regression of CVE-2006-5051 in OpenSSH's sshd creates a race condition where signals are handled unsafely. An unauthenticated remote attacker can trigger it by failing to authenticate within a set time period, potentially leading to remote code execution as root. The flaw affects a broad set of Linux and BSD distributions and network appliances that ship OpenSSH.

Impact

Successful exploitation can give an unauthenticated remote attacker code execution in the context of the sshd process, typically root, on the target host. This can lead to full system compromise, data theft, or use of the host as a pivot point.

Attack surface

Reachable over the network via the SSH service (CVSS AV:N) with no authentication (PR:N) and no user interaction (UI:N). The attacker only needs to connect and fail authentication within the required time window to trigger the race.

Exploitation

Not listed in CISA KEV, but EPSS is extremely high (0.995 probability, 0.999 percentile) and multiple references are tagged Exploit, indicating public exploit activity. No ransomware group usage is documented in the record.

What to do

• Patch OpenSSH to version 9.8 or later, or apply the vendor-supplied fix for your distribution or appliance.
• If immediate patching is not possible, set LoginGraceTime to 0 in sshd_config to remove the timing window, accepting the risk of connection exhaustion.
• Restrict SSH access to trusted networks and management interfaces using firewall rules or network ACLs.
• Monitor vendor advisories for appliance firmware (SonicWall, Arista, NetApp, Apple, etc.) and update as fixes become available.
• Consider using SSH key-only authentication and disabling password authentication to reduce exposure, though this does not fully remove the race condition.

Detection

• Monitor sshd logs for repeated authentication failures or connections that time out without completing authentication, especially in bursts.
• Look for unusual child process crashes, core dumps, or signal-related errors in sshd logs.
• Use network monitoring to detect high volumes of SSH connection attempts from single or distributed sources that fail to authenticate.
• Check for unexpected processes or outbound connections originating from SSH servers that could indicate post-exploitation activity.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.