CVE-2024-6387 | OpenSSH | Critical Remote Code Execution

CVE ID: CVE-2024-6387 Affected Product: OpenSSH server (sshd) versions 8.5p1 through 9.7p1; also affects versions prior to 4.4p1 if unpatched against CVE-2006-5051 CVSS Score: 8.1 (High) — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H Vendor: OpenBSD Project / distributions shipping OpenSSH

Vulnerability Description

CVE-2024-6387, dubbed regreSSHion by Qualys researchers who discovered it, is a signal handler race condition in the OpenSSH server daemon (sshd). The flaw resides in the SIGALRM handler, which calls async-signal-unsafe functions — specifically syslog() — when a client fails to authenticate within the LoginGraceTime window (default: 120 seconds).

Because the signal handler executes in an unsafe context, an unauthenticated remote attacker can corrupt memory and, under the right timing conditions, achieve remote code execution (RCE) as root — without any prior authentication. The attack vector is network-accessible, requires no privileges, and demands no user interaction, making the exploitability surface extremely broad.

The vulnerability class is a regression: an almost identical flaw, CVE-2006-5051, was patched in OpenSSH 4.4p1 in 2006. A code change introduced in OpenSSH 8.5p1 (released October 2020) inadvertently reintroduced the vulnerable pattern, leaving affected versions exposed for nearly four years.

The race condition is reliably exploitable on 32-bit Linux systems with glibc due to heap layout predictability. Exploitation on 64-bit systems is considered theoretically possible but significantly harder due to address space layout randomization (ASLR). Qualys confirmed successful exploitation on 32-bit glibc-based Linux in a controlled environment.

Affected Versions

| Version Range | Status | |---|---| | < 4.4p1 (unpatched CVE-2006-5051) | Vulnerable | | 4.4p1 – 8.4p1 | Not vulnerable | | 8.5p1 – 9.7p1 | Vulnerable (regression) | | 9.8p1 | Patched |

OpenBSD's own deployments are not affected — the operating system implements a separate mitigation that breaks the exploit chain.

Real-World Impact

Shodan and Censys queries performed at the time of disclosure identified approximately 14 million internet-facing OpenSSH instances. Qualys estimated that roughly 700,000 of those were running vulnerable versions based on banner analysis across their customer telemetry.

A successful exploit grants an attacker full root-level code execution on the target host. From that position, an attacker can:

  • Install persistent backdoors or SSH keys
  • Move laterally across internal networks
  • Exfiltrate credentials, keys, and sensitive data
  • Deploy ransomware or wiper payloads
  • Pivot to cloud provider metadata APIs to escalate further

Affected systems include widely deployed Linux distributions shipping vulnerable OpenSSH builds: Ubuntu 22.04 LTS, Debian 12, Fedora 40, Amazon Linux 2023, and others. Most major distributions pushed patches within 24–48 hours of the July 1, 2024 disclosure.

As of the disclosure date, Qualys stated it had not observed active exploitation in the wild, but the research team released a technical write-up and proof-of-concept indicators sufficient for skilled attackers to develop working exploits. Given the attack surface — internet-facing SSH on root-owned processes — SOC teams should treat this as a high-priority remediation item regardless of active exploitation status.

Detection Guidance

Blue teams can look for the following indicators of exploitation attempts:

  • High-frequency connection attempts to port 22 that terminate before authentication completes, particularly if the timing aligns with LoginGraceTime expiry
  • Repeated sshd child process crashes logged via syslog or journald
  • Anomalous sshd parent process spawning unexpected child processes
  • Signatures for the Qualys PoC have been incorporated into Snort and Suricata rule sets (ET OPEN rules updated July 2024)

Vulnerability scanners including Qualys VMDR, Tenable Nessus (Plugin ID 200119), and Rapid7 InsightVM all carry detection coverage for CVE-2024-6387.

Patching and Mitigation

Primary remediation: Upgrade OpenSSH to version 9.8p1 or later. Distributions have backported patches to their supported package branches — use your distribution's package manager to apply the fix.

# Debian/Ubuntu
apt-get update && apt-get install --only-upgrade openssh-server

# RHEL/Amazon Linux/Fedora
dnf update openssh-server

# Verify installed version
ssh -V

Temporary workaround (if patching is not immediately possible):

Set LoginGraceTime 0 in /etc/ssh/sshd_config and restart sshd. This eliminates the signal handler race by disabling the grace period timeout entirely. The trade-off is exposure to connection exhaustion (unauthenticated connections are never automatically cleaned up), so pair this with aggressive firewall rules restricting SSH access to known source IPs.

# /etc/ssh/sshd_config
LoginGraceTime 0

Network-level controls:

  • Restrict SSH access via firewall ACLs to authorized management IPs only
  • Place SSH behind a VPN or bastion host where operationally feasible
  • Enable rate limiting on port 22 at the perimeter or host firewall level

Organizations running container or cloud workloads should audit base images for vulnerable OpenSSH versions and rebuild affected images. Kubernetes nodes, CI/CD runners, and cloud VM templates are common places where outdated SSH server packages persist undetected.

Prioritize internet-facing systems, jump hosts, and any host where sshd runs as root with default configuration — these represent the highest risk exposure.

Related: