regreSSHion OpenSSH RCE vulnerability CVE-2024-6387

On July 1, 2024, the Qualys Threat Research Unit disclosed CVE-2024-6387, nicknamed regreSSHion — a signal handler race condition in OpenSSH's server daemon (sshd) that allows an unauthenticated remote attacker to achieve full root-level remote code execution on affected glibc-based Linux systems. Because OpenSSH is the default remote-access daemon on the overwhelming majority of Linux servers, cloud instances, and network appliances, the disclosure triggered one of the largest coordinated patch pushes of 2024. Qualys estimated more than 14 million internet-exposed OpenSSH instances were potentially vulnerable at time of disclosure, based on Shodan telemetry alone — and that figure doesn't count internal, non-internet-facing hosts sitting behind a perimeter that attackers may still reach after an initial foothold.

The bug is a textbook example of why "fixed" vulnerabilities need long-term regression tracking: CVE-2024-6387 is a reintroduction of CVE-2006-5051, a nearly identical flaw patched almost two decades ago. A refactor in OpenSSH 8.5p1 (released March 2021) inadvertently removed the code that prevented the original race condition, silently reopening a bug the ecosystem had considered closed since 2006.

What the vulnerability actually does

sshd's LoginGraceTime mechanism installs a SIGALRM handler that fires if a client fails to authenticate within the configured grace period (120 seconds by default in most distributions). The problem is that this signal handler calls functions — including syslog() and related memory-allocation routines — that are not async-signal-safe. If the alarm fires while the main thread is in the middle of its own call to one of those same functions, the process can end up in an inconsistent memory state, leading to a use-after-free condition.

Exploiting a race condition of this kind is inherently probabilistic rather than deterministic. In Qualys's own proof-of-concept against a 32-bit Linux target, successful exploitation required roughly 10,000 connection attempts and took on average 6–8 hours. Against 64-bit targets, ASLR (address space layout randomization) dramatically increases the number of attempts needed — Qualys's research suggested exploitation could take on the order of a week of sustained connection attempts to defeat memory-layout randomization and land a working exploit. That complexity is real, but it is not a reason to deprioritize patching: race-condition exploits have a long history of going from "days to land" to "seconds to land" once public tooling matures, and regreSSHion's disclosure was followed almost immediately by widespread internet-wide scanning for vulnerable banners.

Critically, OpenBSD's native sshd is not affected — OpenBSD's signal handling implementation already avoids the unsafe function calls that make this exploitable on other platforms. The vulnerability is specific to Linux and other glibc-based distributions.

Affected versions and components

• Vulnerable: OpenSSH server (sshd) versions 8.5p1 up to, but not including, 9.8p1, when running against glibc.
• Also vulnerable (original, pre-regression bug): OpenSSH versions before 4.4p1, unless they had been backported with the fix for CVE-2006-5051 / CVE-2008-4109.
• Not vulnerable: Versions 4.4p1 through 8.4p1 (the window during which the original fix was intact), and any OpenSSH build linked against a libc other than glibc where the race does not manifest the same way — notably OpenBSD.
• Fixed in: OpenSSH 9.8p1, released alongside the disclosure on July 1, 2024.

Because most enterprise Linux distributions backport security fixes into older OpenSSH package versions rather than shipping upstream releases directly, the actual determining factor for most organizations is whether their distribution's package maintainer had shipped a patched build — not the raw upstream version string. Debian, Ubuntu, RHEL/CentOS/Rocky/Alma, SUSE, Amazon Linux, and most major distributions issued patched packages within days of disclosure, but plenty of long-lived, infrequently-patched appliances, embedded systems, and container base images continued running vulnerable builds for months afterward.

CVSS, EPSS, and exploitation context

CVE-2024-6387 carries an NVD CVSS v3.1 base score of 8.1 (High) — network attack vector, high attack complexity, no privileges required, no user interaction required, and high impact to confidentiality, integrity, and availability if successfully exploited. The "high complexity" component reflects the race-condition timing requirements described above, which is also why the score sits at 8.1 rather than a maximum-severity 9.8 or 10.0 despite the impact (unauthenticated root RCE) being about as severe as it gets.

In the days following disclosure, EPSS (Exploit Prediction Scoring System) scores for this CVE spiked sharply into the upper percentiles, reflecting both the intense public research interest and the wave of internet-wide scanning activity that followed — security teams and honeypot operators widely reported probing traffic consistent with attackers fingerprinting OpenSSH banner versions to build target lists, even before a fully weaponized public exploit for 64-bit systems circulated. As of this writing, we are not aware of confirmed, widely-attributed mass-exploitation campaigns achieving RCE at scale (consistent with the genuine timing difficulty of the race), and the CVE has not been consistently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog to date. That said, "no confirmed mass exploitation yet" is not the same as "safe to ignore" — the combination of a public root-cause writeup, a two-decade-old precedent bug, and millions of exposed instances is exactly the profile that produces exploit tooling over time, and defenders should treat KEV status as a lagging indicator, not a leading one.

Timeline

• 2006: Original race condition patched as CVE-2006-5051; a related issue patched in 2008 as CVE-2008-4109.
• March 2021: OpenSSH 8.5p1 ships with a refactor that inadvertently removes the earlier fix, reintroducing the exploitable code path.
• Early 2024: Qualys TRU identifies the regression during ongoing OpenSSH source review.
• July 1, 2024: Coordinated disclosure — Qualys publishes technical writeup, OpenSSH releases 9.8p1, and Linux distributions begin shipping backported patches.
• July 1–7, 2024: Mass internet scanning for vulnerable OpenSSH banners is observed by multiple security vendors and honeypot networks; distribution maintainers (Debian, Ubuntu, RHEL, SUSE, Amazon Linux, and others) roll out patched packages.
• July–August 2024: Cloud providers and managed hosting platforms push patched base images; enterprise vulnerability scanners and SBOM tooling widely add detection signatures.
• Ongoing: Long-tail exposure persists in unpatched appliances, container images built on stale base layers, and infrequently updated internal servers — the pattern typical of any CVE affecting infrastructure software with long deployment lifecycles.

Remediation steps

1. Patch immediately. Upgrade OpenSSH to 9.8p1 or later, or apply your Linux distribution's backported patch for CVE-2024-6387. This is the only complete fix.
2. Inventory before you patch. Identify every host, container image, and appliance running sshd — including build agents, jump boxes, network gear with embedded SSH, and CI/CD runners, which are commonly missed in ad hoc patch sweeps.
3. Apply a stopgap if patching is delayed. Setting LoginGraceTime 0 in sshd_config disables the vulnerable alarm-based code path as an interim mitigation. Be aware this trade-off removes automatic disconnection of unauthenticated sessions and can make the server more susceptible to connection-slot exhaustion denial-of-service, so pair it with MaxStartups tuning and connection-rate limiting.
4. Restrict exposure at the network layer. Limit SSH access to known management networks or VPN ranges via firewall rules or security groups, and get sshd off the public internet wherever administratively possible. Reducing the attack surface reduces the number of exploitation attempts an attacker can throw at the race condition.
5. Rebuild and redeploy affected container images. Don't just patch running hosts — rebuild any base images pinned to a vulnerable OpenSSH package version so future deployments don't reintroduce the flaw.
6. Monitor for anomalous SSH authentication behavior. High volumes of failed or dropped connection attempts against sshd in a short window are consistent with race-condition exploitation attempts and are worth alerting on, even post-patch, to catch stragglers.
7. Verify remediation with authenticated scanning, not just banner-grabbing, since some distributions backport fixes without incrementing the version string reported by the daemon.

How Safeguard Helps

Patch-everything advice is easy to give and hard to execute across thousands of hosts, images, and repos — which is where Safeguard's platform is built to move faster than a manual sweep. Our SBOM generation and ingestion pipeline continuously inventories OpenSSH and every other package across your fleet and container images, so you get an accurate, always-current answer to "where are we exposed to CVE-2024-6387" instead of a best-effort grep. Griffin AI correlates that component inventory with actual runtime and code-path reachability analysis, distinguishing internet-facing sshd instances that genuinely need same-day attention from internal, network-isolated hosts that can follow standard patch cadence — cutting through alert fatigue on a CVE this widely deployed. Where a fix is as clean as a base-image or package-version bump, Safeguard can open an auto-fix pull request directly against the affected Dockerfile, manifest, or infrastructure-as-code repo, turning triage into a merged patch without a human copying version strings by hand. Together, that reachability-first, SBOM-backed workflow is how Safeguard customers move from "here's a scary CVE" to "here's exactly what's exposed and a PR that closes it" in the same afternoon.