CVE-2024-6387 (regreSSHion): The Critical OpenSSH RCE That Threatened 14 Million Servers

TL;DR: CVE-2024-6387, nicknamed “regreSSHion,” is a race condition in OpenSSH’s SIGALRM signal handler that enables unauthenticated remote code execution as root on glibc-based Linux systems. Affects OpenSSH 8.5p1 through 9.7p1. Disclosed July 1, 2024. Patch to OpenSSH 9.8p1 immediately.

On July 1, 2024, the cybersecurity world woke up to one of the most impactful vulnerabilities in years — a critical remote code execution flaw buried inside OpenSSH, the software that powers secure shell access across hundreds of millions of Linux and Unix servers worldwide. Researchers at Qualys Threat Research Unit (TRU) named it “regreSSHion” — because it is a dangerous regression of a bug that was fixed back in 2006, silently reintroduced in 2020 and left undiscovered for nearly four years.

This is a complete technical deep-dive into CVE-2024-6387: the root cause, exploitation mechanics, affected systems, real-world impact, and exactly how to patch and detect exposure. Whether you are a penetration tester conducting VAPT assessments, a Linux sysadmin managing cloud infrastructure, or a security researcher — this analysis covers everything you need to know.

What is CVE-2024-6387?

CVE-2024-6387 is a signal handler race condition in sshd — the OpenSSH Daemon — that allows an unauthenticated remote attacker to execute arbitrary code as root on vulnerable Linux systems running glibc. The vulnerability received a CVSS v3.1 score of 8.1 (High).

The root issue: when a client connects to an SSH server and fails to complete authentication within the LoginGraceTime window (default: 120 seconds), OpenSSH’s signal handler for SIGALRM calls syslog() — a function that is explicitly not async-signal-safe according to POSIX standards. This can cause a heap memory corruption race condition that, under the right conditions, enables arbitrary code execution.

The History: Why It’s a “Regression”

In 2006, security researchers found an almost identical bug in OpenSSH — CVE-2006-5051 — and it was patched in OpenSSH 4.4p1. The fix stayed in place for 14 years. Then, in October 2020, OpenSSH 8.5p1 was released with various code improvements that inadvertently removed that protection. Nobody noticed. The regression sat silently on millions of servers for nearly four years until Qualys researchers discovered it in June 2024.

Timeline:
• 2006 — CVE-2006-5051 patched in OpenSSH 4.4p1
• October 2020 — OpenSSH 8.5p1 accidentally reintroduces the race condition
• June 2024 — Qualys TRU discovers the regression
• July 1, 2024 — Coordinated disclosure; OpenSSH 9.8p1 released as fix
• July 2024 — Shodan finds 14 million+ exposed vulnerable SSH servers

Technical Root Cause: Async-Signal-Unsafe Functions

OpenSSH sets a LoginGraceTime alarm when a client connects. If authentication isn’t completed in time, the kernel delivers a SIGALRM signal to sshd. The signal handler grace_alarm_handler() is invoked to log the timeout and terminate the connection.

The problem: inside this signal handler, syslog() is called. POSIX defines a strict list of functions safe to call from within signal handlers (async-signal-safe functions). syslog() is not on that list because internally it calls malloc() and other heap management functions.

/* Vulnerable path in OpenSSH sshd (simplified) */
static void
grace_alarm_handler(int sig)
{
    /* syslog() is NOT async-signal-safe — this is the vulnerability */
    syslog(LOG_INFO, "Timeout before authentication for %s port %d",
        ssh_remote_ipaddr(the_active_state),
        ssh_remote_port(the_active_state));
    _exit(EXIT_AUTH_FAILED);
}

If SIGALRM is delivered while the main thread is inside a malloc() or free() call, both the signal handler and the main thread simultaneously modify heap metadata — a classic race condition that corrupts memory and can be leveraged for arbitrary code execution.

Defeating ASLR: The 6–8 Hour Bruteforce

Modern Linux systems use ASLR (Address Space Layout Randomization) to make exploitation harder. For 32-bit Linux glibc systems, ASLR provides only 16 bits of entropy (~65,536 possible address layouts). Qualys demonstrated that by sending approximately 10,000 connection attempts per second, an attacker can statistically win the ASLR lottery within 6 to 8 hours — well within the practical window for a targeted attack.

Affected Versions

Not affected: OpenBSD, Windows-based OpenSSH (glibc-specific issue).

Scale of Exposure: 14 Million Servers

Qualys performed Shodan searches post-disclosure and found over 14 million internet-facing SSH servers running vulnerable OpenSSH versions — AWS EC2, Google Cloud, Azure VMs, DigitalOcean droplets, and bare-metal servers worldwide. This puts regreSSHion in the same tier as Heartbleed (CVE-2014-0160) in terms of raw exposure surface.

Detection: Are You Vulnerable?

# Check your OpenSSH version
ssh -V
sshd -V

# If your version is between 8.5p1 and 9.7p1 — you are vulnerable

# Hunt for exploitation attempts in auth logs
grep "Timeout before authentication" /var/log/auth.log | wc -l
grep "Did not receive identification string" /var/log/auth.log | tail -20

Patching: The Only Complete Fix

# Ubuntu / Debian
sudo apt update && sudo apt upgrade openssh-server -y
sshd -V  # verify 9.8p1 or newer

# RHEL / CentOS / Rocky Linux
sudo dnf update openssh-server -y

# Temporary workaround (until patch is applied)
# Add to /etc/ssh/sshd_config:
LoginGraceTime 0
sudo systemctl restart sshd

Warning: LoginGraceTime 0 disables the authentication timeout, eliminating the race condition but potentially increasing DoS risk via connection exhaustion. Use as a short-term bridge only.

Additional Hardening

• Restrict SSH access by IP via firewall rules or AllowUsers directive
• Disable password authentication: PasswordAuthentication no
• Deploy fail2ban for automated brute-force blocking
• Enable SIEM alerts for unusual volumes of SSH timeout events
• Ensure all internet-facing SSH servers are in your asset inventory with automatic patch alerts

Key Lessons

1. Regression tests for security fixes are mandatory. The 2006 fix had no regression test, so when it was silently undone in 2020, nobody noticed for 4 years.
2. Signal handler code needs special review. Async-signal safety is not widely understood outside systems programming; code review checklists must include it.
3. Patch windows have shrunk to hours, not weeks. With 14 million exposed servers and exploit code publicly available, emergency patching must happen within 24–72 hours for critical SSH vulnerabilities.

Conclusion

CVE-2024-6387 (regreSSHion) proves that even the most trusted, widely-audited software can harbor dangerous vulnerabilities for years. If you manage Linux servers, patch to OpenSSH 9.8p1 now and audit your SSH exposure. For a professional VAPT assessment of your server infrastructure, contact Vivek Verma for a security engagement.

Further reading: More CVE analyses and security research on the VV Blog.