regreSSHion (CVE-2024-6387): The OpenSSH Vulnerability That Exposed Millions of Servers

What Happened

OpenSSH is the most widely deployed SSH implementation in the world. It runs on virtually every Linux server, most BSD systems, macOS, and increasingly on Windows via WSL. When a vulnerability is found in OpenSSH's sshd (the SSH server daemon), the blast radius is enormous.

CVE-2024-6387 is a signal handler race condition in sshd. When a client connects to sshd, a “login grace time” timer starts (default: 120 seconds). If the client does not authenticate within this window, sshd's SIGALRM handler is invoked to clean up the connection. The vulnerability lies in what happens during that signal handler execution.

The SIGALRM handler calls functions that are not async-signal-safe, including syslog() and code paths that invoke malloc()/free(). If the signal arrives while the main process is in the middle of a heap operation (also calling malloc/free), the signal handler corrupts heap metadata. An attacker who can precisely control the timing of their connection attempts can exploit this corruption to achieve arbitrary code execution.

The result: unauthenticated remote code execution as root on any affected Linux system with sshd exposed to the network.

Technical Details

The Race Condition

The core issue is a Time-of-Check Time-of-Use (TOCTOU) race between the main sshd process and its SIGALRM signal handler. Here is the sequence:

1. Client connects to sshd. The server forks a child process to handle the connection and starts a LoginGraceTime timer (default 120 seconds).
2. The main process performs authentication-related operations, including memory allocation (malloc) and deallocation (free) for buffers, key exchange data, and logging.
3. If authentication does not complete within LoginGraceTime, the kernel delivers SIGALRM to the process.
4. The SIGALRM handler runs. In vulnerable versions, it calls sigdie() which calls syslog(), which internally calls malloc().
5. If the signal arrives while the main process is inside malloc/free (holding the heap lock or in the middle of modifying heap metadata), the signal handler's call to malloc corrupts the heap.
6. The attacker exploits this heap corruption to overwrite function pointers or critical data structures, achieving code execution.

Why It Is a Regression

This exact class of vulnerability was fixed in OpenSSH 4.4p1 (2006) as CVE-2006-5051. The original fix made the SIGALRM handler async-signal-safe by only setting a flag, with the actual cleanup deferred to safe points in the main execution flow.

In October 2020, OpenSSH commit 752250c (released as part of OpenSSH 8.5p1) accidentally reintroduced the unsafe signal handler behavior during a refactoring of the logging code. The commit message gives no indication of the security implications. This is why it is called regreSSHion: a regression of a previously fixed security issue.

Affected Versions

• Vulnerable: OpenSSH 8.5p1 through 9.7p1
• Also vulnerable: OpenSSH versions before 4.4p1 (if not patched for CVE-2006-5051)
• NOT vulnerable: OpenSSH 4.4p1 through 8.4p1
• Fixed in: OpenSSH 9.8p1 (released July 1, 2024)

Exploitation Difficulty

The exploit is non-trivial but deterministic. On 32-bit Linux systems, Qualys demonstrated exploitation in approximately 6-8 hours of continuous connection attempts. On 64-bit systems with ASLR, it takes longer (potentially days of attempts) due to the larger address space. However, the exploit requires only network access to port 22 and no authentication credentials.

The exploit does not work against OpenBSD because OpenBSD uses a different, safer signal handling approach. It also does not currently work on systems with certain heap hardening features (some allocator implementations).

Impact: 14 Million Servers

Qualys estimated approximately 14 million internet-facing OpenSSH server instances were potentially vulnerable at the time of disclosure. This estimate is based on Shodan and Censys scan data showing SSH servers accessible from the internet.

The impact is severe:

• Remote Code Execution: The attacker achieves arbitrary code execution
• As Root: sshd runs as root (needed for authentication and privilege separation)
• Unauthenticated: No credentials or keys needed, just network access
• Pre-authentication: The bug triggers before any authentication takes place

This combination (remote + root + unauthenticated + pre-auth) makes regreSSHion one of the most severe OpenSSH vulnerabilities discovered in recent years. It is comparable in impact to EternalBlue (MS17-010) in the SMB world.

Who Is Affected

Any system running OpenSSH 8.5p1 through 9.7p1 with sshd exposed to untrusted networks is potentially affected. This includes:

• Linux servers (cloud VMs, bare metal, VPS instances)
• Container images that include openssh-server
• Kubernetes nodes (host-level sshd)
• CI/CD runners with SSH access enabled
• Network appliances and embedded devices running OpenSSH
• IoT devices with SSH management interfaces

Systems where SSH is only accessible from trusted networks (behind VPN, internal-only) have reduced exposure but are not immune. If an attacker gains access to the internal network through another means, they can exploit regreSSHion for lateral movement.

How to Check If You Are Vulnerable

There are several ways to determine if your systems are affected:

Check OpenSSH Version

Important: On enterprise distributions (RHEL, Ubuntu LTS, Debian stable), the version number alone is not sufficient. These distributions backport security patches without changing the upstream version number. A package version like 1:9.6p1-0ubuntu0.24.04.1 may include the regreSSHion fix even though it shows “9.6p1”. Check your distribution's security advisory for the specific fixed package version.

Scan with ScanRook

ScanRook automatically detects CVE-2024-6387 when scanning container images or system packages. It reads the package database, checks the installed OpenSSH version, and correctly accounts for distribution-specific backported patches using Red Hat OVAL and Debian/Ubuntu security tracker data.

How to Fix It

Option 1: Upgrade OpenSSH (Recommended)

The definitive fix is upgrading to OpenSSH 9.8p1 or later. For most systems, this means updating your distribution's openssh-server package:

Option 2: Temporary Mitigation

If you cannot upgrade immediately, set LoginGraceTime 0 in /etc/ssh/sshd_config. This disables the login timeout entirely, which prevents the SIGALRM signal from being delivered (the trigger for the race condition).

Warning: Setting LoginGraceTime to 0 means sshd will never time out unauthenticated connections. This exposes sshd to connection exhaustion attacks (an attacker can open many connections that are never cleaned up). Use this only as a temporary measure until you can upgrade.

Option 3: Network Controls

Restrict SSH access to trusted IP ranges via firewall rules, security groups, or network ACLs. This does not fix the vulnerability but reduces the attack surface by limiting who can attempt exploitation.

How Backporting Works

Enterprise Linux distributions (Red Hat, Debian, Ubuntu, SUSE) do not simply update to the latest upstream OpenSSH release. Instead, they backport the specific security fix into their supported package version. This means:

• Red Hat Enterprise Linux 9: Ships OpenSSH 8.7p1. The regreSSHion fix was backported into package version openssh-8.7p1-38.el9_4.1. The upstream version still reads as 8.7p1 but the vulnerability is fixed.
• Ubuntu 24.04 LTS: Ships OpenSSH 9.6p1. The fix was backported into package version 1:9.6p1-0ubuntu0.24.04.1.
• Debian 12 (Bookworm): Ships OpenSSH 9.2p1. The fix was backported into package version 1:9.2p1-2+deb12u3.

This is why naive version checking (just looking at the OpenSSH version string) produces false positives on enterprise distributions. A scanner that reports “OpenSSH 8.7p1 is vulnerable” on RHEL 9 without checking the package release version is wrong. ScanRook correctly handles backported patches by using Red Hat OVAL data and distribution-specific security trackers.

Detection with ScanRook

ScanRook detects CVE-2024-6387 automatically during container image scanning. The detection works through multiple mechanisms:

• Package database reading: ScanRook reads the actual package manager database (dpkg, RPM, APK) inside the container image to determine the exact installed version of openssh-server.
• Backport-aware matching: For RHEL-compatible images, ScanRook evaluates Red Hat OVAL definitions that correctly account for backported patches. For Debian/Ubuntu, it uses the distribution security tracker data.
• EPSS enrichment: The finding includes the current EPSS score (historically very high for this CVE, reflecting active exploitation) and CISA KEV status.

In the ScanRook findings view, CVE-2024-6387 will appear with:

• Severity: High (CVSS 8.1)
• EPSS: Very high (indicating active exploitation)
• KEV: Yes (confirmed actively exploited)
• Priority: P0 (requires immediate remediation)

Disclosure Timeline

Lessons for Container Security

regreSSHion offers several important lessons for teams that deploy containerized workloads:

1. Do Not Include SSH in Container Images

The best protection against SSH vulnerabilities in containers is to not ship SSH at all. Most containers do not need sshd. Use kubectl exec or docker exec for interactive access. If you find openssh-server in your container images, ask why it is there and whether you can remove it.

2. Regressions Happen in Mature Software

OpenSSH is one of the most security-audited projects in existence. If a regression can survive 4 years in OpenSSH (2020-2024), it can happen in any software. Continuous scanning catches these regressions when they are disclosed, regardless of how long they have existed.

3. Version Checking Is Not Enough

Naive version-string matching produces both false positives (flagging patched systems) and false negatives (missing vulnerable backported versions). Accurate vulnerability scanning requires understanding distribution-specific patching practices and using authoritative data sources like OVAL and security trackers.

4. EPSS Validates Urgency

CVE-2024-6387 received a CVSS score of 8.1 (High, not Critical) because of the race condition complexity. EPSS correctly flagged it as extremely likely to be exploited because of OpenSSH's ubiquity and the severity of the outcome. Teams using EPSS for prioritization would have treated this as P0 from day one, while teams using only CVSS might have deprioritized it below 9.0+ “Critical” findings.