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

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 or compromised

• 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, 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, released the same day, fixed it. NVD 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 says RHEL 9 is the only affected RHEL release, along with OpenShift 4.13 to 4.16. Ubuntu lists 22.04, 23.10 and 24.04 as fixed in updated packages and 20.04 and earlier as not affected. The Qualys blog 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.

Vulnerability records

• CVE-2024-6387 · A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd).

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Qualys — regreSSHion advisory (CVE-2024-6387) qualys.com
2. Qualys Blog — regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server blog.qualys.com
3. OpenSSH — Release notes 9.8 openssh.org
4. NVD — CVE-2024-6387 nvd.nist.gov
5. Red Hat — CVE-2024-6387 access.redhat.com
6. Ubuntu — CVE-2024-6387 ubuntu.com