regreSSHion (CVE-2024-6387) Explained: A Signal-Handler Race That Reopened an Old OpenSSH RCE

CVE-2024-6387, named regreSSHion, is an unauthenticated remote code execution vulnerability in the OpenSSH server (sshd) on glibc-based Linux systems, rated CVSS v3.1 8.1 (High). It is caused by a signal-handler race condition: if a client fails to authenticate within the login grace period, sshd's alarm handler runs code that is not safe to call from a signal handler, and a skilled attacker can win the race to corrupt memory and execute code as root. Its name reflects that it is a regression — a re-introduction of a bug that OpenSSH had already fixed in 2006.

Timeline and impact

The Qualys Threat Research Unit disclosed regreSSHion on July 1, 2024, coordinated with the release of OpenSSH 9.8p1 the same day. Because sshd is one of the most widely deployed services on the internet, the disclosure prompted an immediate, broad patching effort. Qualys demonstrated working exploitation against 32-bit glibc systems with ASLR in a lab, noting it required winning a race that took many hours of repeated connections — difficult, but far from theoretical, and likely to improve with research and on other architectures.

The most instructive part is how the bug came back. The original issue, CVE-2006-5051, was fixed years ago. Then in October 2020, OpenSSH 8.5p1 refactored its logging code and inadvertently removed a directive that had kept a signal-handler code path safe — silently reintroducing the vulnerability. regreSSHion is therefore a case study in how a security fix can be undone by unrelated maintenance years later, and why "this was patched once" is not the same as "this is patched now." The only reliable defense is continuous version awareness across everything you run.

Technical root cause

sshd enforces a login grace period (LoginGraceTime). If a client does not authenticate in time, sshd raises SIGALRM and the handler tears the connection down. The problem is that this handler calls functions such as syslog(), which are not async-signal-safe — they can allocate memory and manipulate shared state. If the alarm fires while the main program is in the middle of one of those same operations, the interrupted, half-updated state plus the handler's re-entry can be manipulated into a memory-corruption primitive.

Conceptually, the unsafe shape is a signal handler that calls into non-reentrant library code:

/* UNSAFE: SIGALRM can fire at any moment, including while the
   main flow is inside malloc()/free() or logging internals.
   Calling non async-signal-safe functions here races that state. */
static void sigalarm_handler(int sig) {
    syslog(LOG_INFO, "grace period expired");  /* not signal-safe */
    /* ...cleanup that touches shared allocator/log state... */
}

The safe design keeps signal handlers to the bare minimum — set a flag and return — and does the real work in the main loop where no race exists:

static volatile sig_atomic_t timed_out = 0;
static void sigalarm_handler(int sig) { timed_out = 1; }
/* main loop checks `timed_out` and cleans up safely, no
   non-reentrant calls from signal context */

Because the trigger — simply not completing authentication in time — is available to any unauthenticated client, and because success yields code execution as root, regreSSHion sits at the top of the severity spectrum despite the difficulty of the race.

How to detect if you are affected

• Check the sshd version precisely. Affected are OpenSSH 8.5p1 up to (but not including) 9.8p1. Versions 4.4p1 up to 8.5p1 are not vulnerable, because the 2006 fix was intact in that range. Very old releases earlier than 4.4p1 may also be affected if never patched for the original CVE-2006-5051. OpenSSH 9.8p1 and later contain the fix.
• Confirm the platform. The demonstrated impact is on glibc-based Linux. Run ssh -V (or sshd -V where supported) on every host and image.
• Do not rely on the package manager alone. sshd frequently ships inside container base images, appliances, and golden images that never touch the host's updater.

Manifest-only checks miss embedded copies. Safeguard's container security scanning inspects image layers so a vulnerable OpenSSH baked into a base image is flagged even when the host is patched.

Remediation and patched versions

1. Upgrade OpenSSH to 9.8p1 or later (or your distribution's backported fixed build) and restart sshd so the running process picks up the new code.
2. Rebuild and redeploy container images that bundle sshd. A patched host does not fix a stale image still shipping the vulnerable binary.
3. Apply the mitigation only if you cannot patch immediately. Setting LoginGraceTime 0 in sshd_config removes the racing timeout, but it eliminates the grace-period limit and can enable a denial-of-service by exhausting connection slots — treat it as a stopgap, not a fix.
4. Verify across the fleet. Re-inventory hosts and images after rollout; stale images are the usual reason a "fixed" finding reappears.

How Safeguard surfaces and auto-fixes regreSSHion

regreSSHion is exactly the kind of finding Safeguard is built for: a security-critical component that hides in base images and golden builds, where the vulnerable version can differ from what a host's package list suggests. Safeguard resolves the full component inventory across your repositories and container images and matches it against vulnerability intelligence, so a vulnerable OpenSSH several layers deep in an image is surfaced with the exact path from your artifact to the affected binary. Findings are enriched with CISA KEV and EPSS signals so an unauthenticated, root-level sshd RCE is prioritized, and the Safeguard CLI lets you fail a build in CI before a vulnerable image is ever published. Deep software composition analysis is what makes the embedded, transitive case visible in the first place.

Where the fix is a version bump, automated fix pull requests propose the OpenSSH upgrade directly against your image definitions and manifests, and Griffin AI explains the regression story and the DoS trade-off of the LoginGraceTime 0 mitigation so you choose deliberately. If you are evaluating scanners on how well they catch OS packages embedded in images, our side-by-side comparison covers that ground directly.

A logging refactor quietly reopened a bug fixed in 2006. The tooling that catches that is the same tooling that catches every future sshd advisory: continuous, deep inventory of what your images actually ship.

Get started at app.safeguard.sh/register, or read the documentation at docs.safeguard.sh.