How to Fix CVE-2024-6387 (regreSSHion) in OpenSSH < 9.8

CVE-2024-6387, known as regreSSHion, is a race condition in the OpenSSH server (sshd) that can let an unauthenticated attacker run code as root on glibc-based Linux. It affects OpenSSH 8.5p1 through 9.7p1. The CVE-2024-6387 regreSSHion fix is to upgrade to OpenSSH 9.8p1 or install your distribution’s patched openssh-server package, then restart sshd.

If you cannot patch yet, LoginGraceTime 0 is a temporary workaround. Most distributions backported the fix without changing the version number, so many banner-based hits on patched hosts are false positives.

What the scanner is actually detecting

In Nessus the finding is titled OpenSSH < 9.8 RCE, plugin ID 201194, in the Misc. family. It is a remote check: Nessus reads the version string the SSH server announces in its banner and compares it to 9.8. Tenable’s plugin description states that Nessus has not tested for the flaw itself and relies only on the application’s self-reported version number. The plugin covers two CVEs:

• CVE-2024-6387: the sshd signal handler race condition (regreSSHion) in Portable OpenSSH 8.5p1 through 9.7p1.
• CVE-2024-39894: a logic error in the ObscureKeystrokeTiming feature of OpenSSH 9.5 through 9.7 that weakened a protection against keystroke timing attacks. It is a lower severity issue (Ubuntu rates it medium priority). CVE-2024-39894 affects the ssh client (ssh(1)), not sshd, so update openssh-client on hosts that initiate SSH sessions, such as admin workstations. On Ubuntu 24.04 the fix is 1:9.6p1-3ubuntu13.4 (USN-6887-1); Ubuntu 23.10, 22.04 and older are not affected. The server-side steps and the LoginGraceTime workaround below do not cover it.

Qualys, whose Threat Research Unit discovered and named the bug, published detections for the affected distributions plus an OS-independent check, and notes that the OS-independent detection needs root privileges to be accurate. The vulnerable ranges, per the Qualys advisory and the OpenSSH 9.8 release notes:

OpenBSD is not vulnerable.

Real-world risk

On paper the flaw is severe: no credentials, no user interaction, default configuration, and code runs as root. It is a regression of CVE-2006-5051, hence the name. When a client fails to authenticate within LoginGraceTime (120 seconds by default), sshd’s SIGALRM handler calls functions that are not async-signal-safe, such as syslog(), and an attacker who wins that race can corrupt memory.

In practice, exploitation is slow and noisy. The OpenSSH 9.8 release notes say it was demonstrated on 32-bit Linux/glibc with ASLR and needed on average 6 to 8 hours of continuous connections, up to the maximum the server accepts, under lab conditions. Exploitation on 64-bit systems was believed possible but had not been demonstrated when the fix shipped. Tenable marks a public exploit as available. Patch internet-facing SSH on affected versions first and internal hosts on your normal high severity schedule; for deadlines, see our guide to patch SLA timelines by severity.

How to confirm it on the host

Start with what the scanner sees. From any machine, print the server’s version string:

ssh -v -o BatchMode=yes host exit 2>&1 | grep 'remote software version'

Debian and Ubuntu append the package revision to the banner (for example OpenSSH_8.9p1 Ubuntu-3ubuntu0.10) because the DebianBanner option defaults to yes. RHEL-family banners show only the upstream version, such as OpenSSH_8.7, so you have to check the package on the host.

On RHEL 9 and its rebuilds, check the package and its changelog:

rpm -q openssh-server
rpm -q --changelog openssh | grep CVE-2024-6387

A patched package prints a line such as “Possible remote code execution due to a race condition (CVE-2024-6387)”. No output on an 8.7p1 package means the fix is missing.

On Debian and Ubuntu, compare the installed version with the fixed version for your release (listed in the next section). You must set FIXED to the value for your release. The comparison is only meaningful against the right threshold: an unpatched Ubuntu 24.04 or Debian 12 package still sorts above the Ubuntu 22.04 value, so reusing it would print “patched” on a vulnerable host.

dpkg-query -W openssh-server
FIXED=1:9.6p1-3ubuntu13.3   # noble; jammy: 1:8.9p1-3ubuntu0.10; bookworm: 1:9.2p1-2+deb12u3
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' openssh-server)" ge "$FIXED" && echo patched || echo "not patched"

On Ubuntu 24.04, use 1:9.6p1-3ubuntu13.4 instead to cover CVE-2024-39894 as well.

Check whether the workaround is already active. sshd -T prints the effective configuration after all include files are read:

sudo sshd -T | grep -i logingracetime

The race is triggered through login timeouts, which sshd logs as “Timeout before authentication”. A few are normal; a steady stream from one source over hours deserves a closer look:

sudo journalctl -t sshd --since "7 days ago" | grep "Timeout before authentication"

How to fix it

RHEL 9 and its rebuilds

Red Hat states that only RHEL 9 is affected; RHEL 6, 7 and 8 use older OpenSSH versions that never had the bug. The fix shipped in RHSA-2024:4312 as openssh-8.7p1-38.el9_4.1, and later RHEL 9 builds carry it as well. Rocky Linux shipped the same version in BaseOS.

sudo dnf upgrade openssh openssh-server openssh-clients
sudo systemctl restart sshd

Ubuntu

If you were planning to upgrade OpenSSH to 9.8 on Ubuntu, you do not need to. Canonical backported the fix in USN-6859-1 and kept the upstream version number:

sudo apt update
sudo apt install --only-upgrade openssh-server
sudo systemctl restart ssh

Debian

Debian 12 (bookworm) is fixed in 1:9.2p1-2+deb12u3 (DSA-5724-1). Debian 11 (bullseye) is not affected, because the vulnerable code arrived in 8.5p1. Use the same apt commands as Ubuntu; the service is also named ssh.

Other distributions, appliances and source builds

Other distributions, including SUSE, Fedora, Alpine and Amazon Linux, published their own advisories; look up CVE-2024-6387 in your vendor’s tracker and compare package versions, not banners. Appliances need vendor firmware. If you run a self-compiled OpenSSH, install the current Portable OpenSSH release (9.8p1 or later) following its INSTALL file, and read the compatibility notes under “What can break” first.

Temporary workaround: LoginGraceTime 0

Both the Qualys advisory and Red Hat give the same regreSSHion LoginGraceTime 0 workaround. With no login time limit, the SIGALRM handler never fires, so the race cannot be triggered. sshd uses the first value it reads for each keyword, and the Debian, Ubuntu and RHEL 9 packages include /etc/ssh/sshd_config.d/*.conf near the top of the main file. On those systems, a drop-in that sorts first is the cleanest option:

echo 'LoginGraceTime 0' | sudo tee /etc/ssh/sshd_config.d/00-cve-2024-6387.conf
sudo sshd -t && sudo systemctl restart sshd    # service is "ssh" on Debian/Ubuntu
sudo sshd -T | grep -i logingracetime

If your sshd_config has no Include line, add LoginGraceTime 0 near the top of /etc/ssh/sshd_config instead. Qualys states the trade-off plainly: sshd becomes open to a denial of service that exhausts all MaxStartups connections, because unauthenticated connections are never dropped. Limit port 22 to management networks while the workaround is in place. It also does nothing for CVE-2024-39894 and does not change the banner, so plugin 201194 stays open until you patch.

How to verify the fix and rescan

1. Re-run the package checks above: the RPM changelog should list CVE-2024-6387, or the dpkg comparison, with FIXED set to your release’s fixed version, should print “patched”.
2. Confirm sshd was restarted after the update. Compare systemctl show -p ActiveEnterTimestamp sshd (use ssh on Debian/Ubuntu) with the package install time from rpm -q –last openssh-server or /var/log/dpkg.log.
3. On Debian and Ubuntu, the banner’s revision suffix should now show the fixed version.
4. Rescan with credentials. Authenticated scans let Nessus and Qualys run their local distribution package checks, which understand backports. Our guide to setting up SSH credentials for Linux authenticated scans covers the account and sudo setup. Those local package plugins (the RHSA-2024:4312, USN-6859-1 and DSA-5724-1 checks) are the proof of the fix, not plugin 201194. Because 201194 is a remote banner check, a credentialed scan does not necessarily clear it: on patched RHEL 9 the banner still reads OpenSSH_8.7 with no release suffix, so 201194 can keep firing. If it does on RHEL 9 or its rebuilds, close it as a documented false positive or accepted exception, using the rpm changelog output as evidence.

What can break and how to roll back

A distribution package update is low risk. Restarting sshd does not normally end existing sessions, but keep a second session or an out-of-band console open in case the new daemon fails to start. To roll back, use sudo dnf downgrade openssh openssh-server openssh-clients on RHEL, or, on Debian/Ubuntu, pin all three binary packages to the same previous version: sudo apt install openssh-server=<prev> openssh-client=<prev> openssh-sftp-server=<prev>. openssh-server depends on openssh-sftp-server, and both require an exactly matching openssh-client, so downgrading only two of them leaves unmet dependencies. Include any other installed package built from the same source, such as ssh-askpass-gnome. Rolling back reinstates the vulnerability, so treat it as a short-term step.

Moving a source build to upstream 9.8 or later brings changes the release notes flag as potentially incompatible:

• The DSA signature algorithm is disabled at compile time, so any remaining ssh-dss keys stop working.
• sshd is split into a listener (sshd) and a per-session binary (sshd-session), and some log lines are tagged sshd-session. Log parsers and fail2ban filters that match on the process name may need updating.
• The server now blocks addresses that repeatedly fail authentication or connect without authenticating. Monitoring probes or clients behind a shared NAT address can get caught; exempt trusted ranges with PerSourcePenaltyExemptList.

To roll back the workaround, delete the drop-in (or the line in sshd_config), run sshd -t, and restart the service.

Common false positive reasons

• Backported distribution package. RHEL 9 (8.7p1), Ubuntu 22.04 (8.9p1), Ubuntu 24.04 (9.6p1) and Debian 12 (9.2p1) all carry the fix below 9.8. If the changelog or package version shows the fix, treat a banner-only Nessus hit as a false positive and keep the command output as evidence. Our article on backported patch false positives explains why this keeps happening.
• Version outside the vulnerable range. RHEL 7 (7.4p1), RHEL 8 (8.0p1), Ubuntu 20.04 (8.2p1) and Debian 11 (8.4p1) predate 8.5p1 and are not affected by CVE-2024-6387. Check the plugin output to see which version was matched.
• OpenBSD. The OpenSSH project states OpenBSD is not vulnerable.

Some results look like false positives but are not: a host with only the workaround applied (mitigated, still unpatched), a package that was updated without restarting sshd, or a port forward or load balancer that sends the scanner to a different machine than the one you patched.

FAQ

Does LoginGraceTime 0 fix CVE-2024-6387?

It removes the remote code execution path, according to Qualys, but leaves sshd open to connection slot exhaustion and does not change the reported version. Use it as a stopgap and patch.

Do I need OpenSSH 9.8 on Ubuntu or RHEL?

No. Install the vendor’s patched package; RHEL, Ubuntu and Debian backported the fix into their existing versions.

How do I check if OpenSSH is vulnerable to regreSSHion?

Check the installed package, not the banner: rpm -q –changelog openssh | grep CVE-2024-6387 on RHEL-family systems, or compare dpkg-query -W openssh-server with your release’s fixed version on Debian and Ubuntu.

Are 64-bit servers exploitable?

The OpenSSH developers said 64-bit exploitation was believed possible but had not been demonstrated at release. That lowers urgency slightly; it is not a reason to skip the patch.

Tracking this finding across many hosts

With a mixed Linux fleet, the work is sorting real exposure from backport noise and proving each host stayed fixed. If you use SITEY, you upload the .nessus export, and AI triage suggests possible false positives with supporting evidence while a human makes the final call. For hosts that do need the update, AI drafts a host-specific remediation script that runs only after human approval through its agents on Linux endpoints, and a per-finding Nessus retest confirms closure.

Sources

• Tenable: Nessus plugin 201194, OpenSSH < 9.8 RCE
• Qualys: regreSSHion technical advisory (CVE-2024-6387)
• Qualys blog: regreSSHion detections and QIDs
• OpenSSH 9.8 release notes
• Red Hat: CVE-2024-6387
• Ubuntu: CVE-2024-6387
• Ubuntu: CVE-2024-39894