---
title: "regreSSHion: OpenSSH sshd Signal Race RCE (CVE-2024-6387)"
url: https://erroneo.us/security/briefs/regresshion-openssh-signal-race-cve-2024-6387/
description: "Unauthenticated root RCE race in OpenSSH 8.5p1-9.7p1 on glibc Linux; fixed in 9.8p1 and distro updates. Hard to exploit, so patch on normal cadence."
type: security-brief
section: "Security Digest"
date_published: 2024-07-01
date_modified: 2026-10-21
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Patch this week"
cves: ["CVE-2024-6387"]
severity: "high"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# regreSSHion: OpenSSH sshd Signal Race RCE (CVE-2024-6387)

**Verdict: Patch this week.** Serious on paper (unauthenticated root RCE in sshd), but the only demonstrated exploit needed a 32-bit glibc target and 6-8 hours of continuous connections in a lab, so patch promptly through your distro instead of panicking.

- **Who must act:** Owners of glibc-based Linux hosts running OpenSSH 8.5p1 through 9.7p1 (for example Ubuntu 22.04/24.04, RHEL 9) with sshd reachable from untrusted networks, above all 32-bit systems or builds without per-connection ASLR re-randomization.
- **Who can relax:** OpenBSD, OpenSSH 4.4p1 through 8.4p1 (e.g. RHEL 8, Ubuntu 20.04), Windows OpenSSH per Qualys, and hosts whose sshd is reachable only from a trusted network or bastion.
- **Affected:** OpenSSH 8.5p1 up to (not including) 9.8p1 on glibc-based Linux; OpenSSH before 4.4p1 unless patched for CVE-2006-5051 and CVE-2008-4109; RHEL 9 and OpenShift 4.13-4.16 (per Red Hat); Ubuntu 22.04, 23.10, 24.04 before fixed packages
- **Fixed:** OpenSSH 9.8p1; Ubuntu 24.04: 1:9.6p1-3ubuntu13.3; Ubuntu 22.04: 1:8.9p1-3ubuntu0.10; RHEL 9: updated openssh via Red Hat errata
- **CVEs:** CVE-2024-6387
- **CISA KEV:** no · **Exploitation:** No known exploitation

## What to do

1. Check the installed version with `ssh -V` and your package manager (`dpkg -l openssh-server` / `rpm -q openssh-server`)
2. Install your distribution's patched openssh-server and restart sshd
3. Restrict sshd to VPN, bastion or allow-listed IPs; do not leave port 22 open to the world
4. If you cannot patch, set `LoginGraceTime 0` in sshd_config and restart, accepting DoS risk, and remove it after patching
5. Prioritize 32-bit and appliance-style Linux builds that are slow to receive updates

### How to check if you are affected

- Look for large volumes of `Timeout before authentication` messages in sshd logs from a single source, the signature of repeated race attempts
- Watch for MaxStartups exhaustion (`beginning MaxStartups throttling`) and sustained connection floods on port 22
- Inventory versions fleet-wide: `ssh -V` or an authenticated scanner, since the SSH banner alone does not show distro backports

## What happened

On July 1, 2024 Qualys disclosed [regreSSHion](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt), a signal handler race condition in OpenSSH's server. If a client does not authenticate within `LoginGraceTime` (120 seconds by default), sshd's SIGALRM handler fires and calls functions that are not async-signal-safe, including logging code that can reach `malloc`. On glibc-based Linux this happens in privileged, unsandboxed code, so winning the race can mean code execution as root with no credentials.

The name comes from its history: this is a regression of CVE-2006-5051, reintroduced in OpenSSH 8.5p1 in October 2020. [OpenSSH 9.8](https://www.openssh.org/txt/release-9.8), released the same day, fixed it. [NVD](https://nvd.nist.gov/vuln/detail/CVE-2024-6387) and Red Hat both score it CVSS 3.1 8.1, with the high attack complexity (AC:H) reflecting the race.

## Who is affected

Vulnerable: OpenSSH 8.5p1 up to but not including 9.8p1, plus ancient releases before 4.4p1 that never got the 2006 and 2008 fixes. Versions 4.4p1 through 8.4p1 are not affected, and neither is OpenBSD. Qualys says Windows is not vulnerable, while macOS exploitability was left uncertain. In distribution terms, [Red Hat](https://access.redhat.com/security/cve/cve-2024-6387) says RHEL 9 is the only affected RHEL release, along with OpenShift 4.13 to 4.16. [Ubuntu](https://ubuntu.com/security/CVE-2024-6387) lists 22.04, 23.10 and 24.04 as fixed in updated packages and 20.04 and earlier as not affected. The [Qualys blog](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server) cited over 14 million potentially vulnerable OpenSSH servers visible to Censys and Shodan. That is a version-banner estimate, not a count of exploitable machines.

## Do you really need to act?

Patch, yes. Drop everything, usually no. The exploitation reality is sobering for attackers:

- The only working exploit Qualys described targeted **32-bit (i386) glibc**. It needed about 10,000 attempts on average. At the default 100 concurrent unauthenticated connections per 120-second window, that is roughly 3 to 4 hours to win the race, and about **6 to 8 hours** to get a root shell because of ASLR.
- On **amd64**, Qualys had no working exploit at disclosure and had put that work on hold. The OpenSSH release notes say 64-bit exploitation is believed possible but had not been demonstrated.
- Red Hat notes the attack "requires significant resources," and that thousands of retries make it noisy and detectable.
- Qualys did not publish its exploit code. As of October 21, 2026 the CVE is not in CISA's KEV catalog, and we found no confirmed in-the-wild exploitation.

The risk is higher for systems without ASLR or with per-connection re-randomization disabled, for 32-bit embedded and appliance builds that rarely see updates, and for sshd exposed to the whole internet. Those deserve priority. A 64-bit cloud VM behind a bastion can take the fix on your normal weekly cycle.

## What to do now

1. Check versions: `ssh -V`, `dpkg -l openssh-server` or `rpm -q openssh-server`. Distros backport fixes, so compare against your vendor's fixed package, not just the upstream number.
2. Update openssh-server from your distribution and restart `sshd`.
3. Limit who can reach port 22: VPN, bastion, security-group allow lists.
4. If patching must wait, set `LoginGraceTime 0`. This removes the code execution path but lets attackers exhaust `MaxStartups` and deny service. Red Hat warns that the setting is not removed automatically when you later patch.
5. Chase down long-tail devices (appliances, 32-bit boxes) first.

## How to tell if you were hit

A real attempt is loud. Expect thousands of connections that never authenticate, each ending in a grace-time timeout, often with `MaxStartups` throttling messages in sshd logs. Sustained floods like that from one source are worth investigating and blocking even on patched hosts. A successful attack would leave the usual root-compromise traces: new keys in `authorized_keys`, unknown processes or cron jobs.

## Timeline

- Oct 2020 — OpenSSH 8.5p1 reintroduces the bug.
- May 19, 2024 — Qualys contacts OpenSSH developers.
- Jun 20, 2024 — Linux distributions notified via distros@openwall.
- Jul 1, 2024 — Coordinated disclosure. OpenSSH 9.8 released.

## Sources

1. [Qualys — regreSSHion advisory (CVE-2024-6387)](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt)
2. [Qualys Blog — regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server)
3. [OpenSSH — Release notes 9.8](https://www.openssh.org/txt/release-9.8)
4. [NVD — CVE-2024-6387](https://nvd.nist.gov/vuln/detail/CVE-2024-6387)
5. [Red Hat — CVE-2024-6387](https://access.redhat.com/security/cve/cve-2024-6387)
6. [Ubuntu — CVE-2024-6387](https://ubuntu.com/security/CVE-2024-6387)

---
Source page: https://erroneo.us/security/briefs/regresshion-openssh-signal-race-cve-2024-6387/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt