regreSSHion: a race condition in sshd, reachable before anyone logs in
A pre-authentication remote code execution bug in the most exposed daemon on a Linux server. It is also a regression: the same flaw was fixed in 2006 and came back in 2020 when the fix was accidentally removed.
A fixed package version is available on 5 of the releases below. Each row names the version, and the section below it says when this does not apply to you at all.
What it actually is
sshd sets an alarm to disconnect clients that take too long to authenticate. The handler that runs when that alarm fires calls functions that are not safe to call from a signal handler. A client that arrives at exactly the wrong moment can leave the daemon in a state an attacker can steer, and sshd runs as root.
What an attacker gets: Remote code execution as root, with no credentials and no account on the target.
When it applies to you, and when it does not
An old package version and a real exposure are different things. These are the conditions this one needs.
- Only the OpenSSH server matters here, not the client. A machine with openssh-client installed and no sshd running is not exposed by this.
- It affects glibc-based Linux. A musl system such as Alpine is not in scope, and neither is OpenBSD, where the 2020 regression never applied.
- Exploitation is difficult and noisy. Public research described it as needing thousands of connection attempts against a default configuration, which is exactly the kind of traffic a rate limit or a brute-force block stops long before it succeeds.
Check your own server
sshd -V 2>&1 | head -1Prints the running server version. Compare the package version in the table below, not this one: distributions backport the fix without changing it.
If you cannot patch today
Setting `LoginGraceTime 0` in sshd_config removes the alarm the bug depends on, at the cost of making the daemon easier to exhaust with open connections. It is a stopgap for a machine that cannot be patched today, not a fix.
Fixed package version, per distribution
From each distribution’s own advisory data, asked per release. A version here is the package version that carries the fix on that release, not the upstream release number.
| Release | Source package | State | Fixed in |
|---|---|---|---|
| Ubuntu 22.04 LTS | openssh | Fixed | 1:8.9p1-3ubuntu0.10 |
| Ubuntu 24.04 LTS | openssh | Fixed | 1:9.6p1-3ubuntu13.3 |
| Debian 12 (bookworm) | openssh | Fixed | 1:9.2p1-2+deb12u3 |
| Debian 13 (trixie) | openssh | Fixed | 1:9.7p1-7 |
| Rocky Linux 9 | openssh | No advisory names it | No Rocky Linux 9 advisory names it. AlmaLinux 9, rebuilt from the same Red Hat Enterprise Linux 9 source, fixed it in 8.7p1-38.el9_4.1 (ALSA-2024:4312). |
| AlmaLinux 9 | openssh | Fixed | 8.7p1-38.el9_4.1 |
Install the fix with apt update && apt install --only-upgrade openssh-server openssh-client on Debian and Ubuntu, or dnf update openssh-server openssh-clients on Rocky Linux and AlmaLinux. Restart whatever was using it afterwards: a patched file on disk is not a patched process in memory.
What SecAI has recorded about it
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
Recorded from nvd. Its weakness class is CWE-364 and CWE-362, from NVD.
Read next
Other CVEs explained in full
Then check the rest of the server
The command above shows which version you run, and the table shows which version fixes CVE-2024-6387. One more read-only command, with no account and no agent, checks the rest of the server’s setup: SSH, the firewall, how many security updates are waiting, and signs that it has already been compromised. It changes nothing. It does not match your packages against advisories; SecAI’s agent does that, checking installed packages against published advisories every 12 hours.