A deep dive into the unauthenticated RCE in OpenSSH's signal handler, why it matters even without reliable exploitation, and what you should have done on day one.
CVE-2024-6387, dubbed RegreSSHion, is a critical unauthenticated remote code execution vulnerability in OpenSSH's server daemon (sshd). With a CVSS base score of 8.1 and active proof-of-concept code published within 72 hours of disclosure, it became one of 2024's most watched vulnerabilities. Here is what happened, why it is technically significant, and what your team should have done the moment it dropped.
The root cause is a classic UNIX signal-handling race condition that was actually fixed in OpenSSH 4.4 back in 2006 - and then accidentally reintroduced sometime around 2020. That regression is why the name "RegreSSHion" stuck.
When a client connects to sshd and does not complete authentication within the LoginGraceTime window (default: 120 seconds), sshd sends SIGALRM to terminate the connection. The problem is that the SIGALRM handler calls functions that are not async-signal-safe - including the memory allocator. If a SIGALRM fires while the main thread is inside malloc or free, the heap can be corrupted.
An attacker can exploit this window by repeatedly connecting and timing connections to trigger the race condition repeatedly. Over thousands of attempts, the heap corruption becomes controllable enough to hijack execution flow. The attack is probabilistic: Qualys, who discovered the bug, estimated success rates of 6-8 hours on a 32-bit glibc Linux system. On 64-bit systems, ASLR makes reliable exploitation significantly harder - but not impossible.
OpenSSH versions earlier than 4.4 were already vulnerable to the original bug. The regression means versions from approximately 8.5p1 through 9.7p1 are affected.
The critical population is anything running a standard Linux distribution with sshd exposed to the internet - which is most of the world's servers.
The absence of a weaponized, reliable exploit is not a reason to deprioritize patching. Here is why:
First, the vulnerability appears in the CISA Known Exploited Vulnerabilities catalog - not because CISA observed confirmed in-the-wild exploitation, but because the quality of the public PoC code was deemed sufficient to create a realistic exploitation timeline. CISA KEV classification is the highest-confidence signal that real-world weaponization is imminent or occurring.
Second, the attack is noisy but not impossible. Nation-state actors and advanced persistent threat groups routinely operate in timeframes (6-8 hour attack windows) that make probabilistic exploitation viable against high-value targets.
Third, 14 million+ internet-exposed OpenSSH servers were running vulnerable versions at disclosure time according to Shodan data. The sheer attack surface means even low-probability exploitation becomes statistically significant.
Patch immediately. OpenSSH 9.8p1 was released alongside the disclosure. Most distributions shipped patches within 24 hours:
If immediate patching was not possible, the official mitigation was to set LoginGraceTime 0 in /etc/ssh/sshd_config. This disables the authentication timeout entirely, which eliminates the race condition window but also removes a DoS protection. Acceptable as a temporary measure.
Teams relying on weekly or monthly scan cycles found out about CVE-2024-6387 days or weeks after their internet-facing servers were already in the vulnerable window. Teams with real-time CVE monitoring matched to their stack knew within minutes of NVD publication and had tickets open before the end of the day.
RegreSSHion highlighted a detection gap that affects almost every engineering team: knowing you run OpenSSH is not the same as knowing which version you run, on which hosts, and whether those hosts are internet-exposed.
The teams who responded fastest had three things in place: 1. An accurate, current software inventory tied to their infrastructure (not just their repos) 2. A CVE monitoring system that matched new disclosures against that inventory in real time 3. An escalation path that went directly to the engineer responsible for that infrastructure - not a JIRA ticket queue that got reviewed at the next sprint
The gap between publishing and patching is a tooling and process gap, not a competence gap. RegreSSHion just made it visible again.
Takeaway
CVE-2024-6387 is now patched on most well-maintained systems, but it will not be the last critical OpenSSH vulnerability. The lesson is not "patch OpenSSH" - it is that your detection-to-patch pipeline needs to be measured in hours, not days. If your team found out about RegreSSHion from Twitter or a colleague rather than from an automated alert tied to your actual infrastructure, that is the problem to solve.