CVE-2024-6387 (regreSSHion): OpenSSH pre-auth RCE that's real but hard to exploit

March 23, 2025By BreachBits Threat Team4 min readModerate severityThreatsAttack surface

The short version: regreSSHion (CVE-2024-6387) is a signal-handler race condition in OpenSSH's server (sshd) that can, in principle, give an unauthenticated attacker remote code execution as root on glibc-based Linux. It's a genuine pre-auth RCE — but exploitation is slow (hours of attempts), was only demonstrated on 32-bit systems, and it is not in CISA's KEV catalog. Steady hands: patch in your normal cadence to OpenSSH 9.8, don't panic.

At a glance

Fact	Detail
Our severity take	Moderate — on paper; practically hard to exploit (see below)
CVSS v3.1 (NVD)	8.1 — High · `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`
EPSS	99.5% · 99.9th percentile (2026-07-17)
In CISA KEV?	No — not listed as of writing
Known exploited?	Not confirmed at scale — a regression of a 2006 bug; exploitation demonstrated but difficult
Vulnerability type	CWE-362 / CWE-364 signal-handler race condition → unauthenticated remote code execution as root
Requires authenticated session?	No — pre-authentication
Affected	OpenSSH `sshd` 8.5p1 through 9.7p1 on glibc-based Linux (default config)
Fixed in	OpenSSH 9.8 / 9.8p1 (or vendor backports)

What you need to know

CVE-2024-6387 is a race condition in how sshd handles a signal when a login attempt times out. It's a "regression" — the same class of bug as CVE-2006-5051, reintroduced in OpenSSH 8.5p1 by a 2020 logging change. Under the right timing, an attacker can reach an unsafe function during the async signal handler and, in principle, execute code as root before authenticating.

The headline is frightening — unauthenticated root RCE, millions of exposed servers — so it's worth being precise about the practical picture:

It's a race, and races are finicky. Public research put successful exploitation at roughly 6–8 hours of repeated attempts, generating many connections that look like brute-force noise.
Only demonstrated on 32-bit glibc Linux. It has not been shown exploitable on 64-bit systems, and Windows and macOS aren't affected. OpenBSD isn't vulnerable at all.
The tell is loud. Exploitation floods logs with "Timeout before authentication" lines — noisy and detectable.
It's default-config. The exposure is broad (any affected sshd in the vulnerable version range), even if turning that exposure into code execution is hard.

How serious we see it

Moderate — matching the 8.1 base score, and this time the "gap" runs the other way from the scary headline.

The AC:H (high attack complexity) in the vector is doing honest work: this is a real pre-auth RCE, but it is slow, unreliable, has not been demonstrated against modern 64-bit servers, and is not in CISA's KEV catalog. The very high EPSS reflects how many systems could be targeted, not a track record of easy mass compromise. So: patch it, deliberately and promptly — but this is a "fix it on a sensible schedule" flaw, not a drop-everything perimeter emergency.

The bounded, reassuring part: the affected version range is specific, the fix is published, a config mitigation exists, and you can quickly determine which of your sshd instances are in scope.

Recommendations

Straight from the OpenSSH release notes and the Qualys advisory:

Patch now. Upgrade to OpenSSH 9.8 / 9.8p1, or apply your distribution's backported fix.
If you can't patch immediately, mitigate. Setting LoginGraceTime 0 in sshd_config closes the race — but be aware it makes the server more prone to connection-exhaustion (DoS), so treat it as temporary.
Reduce exposure. Restrict sshd to trusted networks or a bastion where you can; don't leave management SSH open to the whole internet.
Watch the logs. Alert on floods of "Timeout before authentication" — the signature of exploitation attempts.
Confirm your exposure first. Verify which internet-facing SSH services run an affected OpenSSH build on glibc Linux.

How BreachRisk sees it

BreachRisk discovers internet-facing SSH services across your external footprint, fingerprints the OpenSSH version, and flags those in the affected range so you can prioritize the patch. Because turning this race into code execution is slow, unreliable, and potentially disruptive, BreachRisk does not attempt to exploit it — it detects and flags the vulnerable, exposed service rather than firing thousands of attempts at your sshd.

That's the honest line: we tell you where the affected SSH lives, ranked by real-world risk, so you can patch calmly instead of reacting to a headline.