RegreSSHion (CVE-2024-6387): what it means for your Linux servers and how to patch fast

A race condition in OpenSSH's signal handler allows unauthenticated remote code execution on glibc-based Linux systems. Here's the exploit in plain terms, how to check whether you're genuinely exposed, and why your scanner may be lying to you.

What the vulnerability is

CVE-2024-6387 — nicknamed regreSSHion — is an unauthenticated remote code execution flaw in OpenSSH's server, sshd, on glibc-based Linux systems. It earned attention for two reasons: it needs no credentials, and it's a regression of a vulnerability fixed back in 2006 (CVE-2006-5051) that was reintroduced in OpenSSH 8.5p1.

How it works, briefly

When a client fails to authenticate within LoginGraceTime (120 seconds by default), sshd raises SIGALRM and runs a signal handler. That handler calls functions which are not async-signal-safe — meaning they aren't safe to invoke from inside a signal handler while other code may be mid-execution.

An attacker who lets the grace timer expire at a precisely controlled moment can interrupt a heap operation partway through, leaving memory in a manipulable state, and ultimately achieve code execution as root.

It's a race condition, so exploitation is not instant. Public research demonstrated it taking many hours of repeated attempts against a 32-bit system. That's a meaningful mitigating factor — but it is not a fix, and it is not a reason to defer patching.

Are you actually vulnerable?

Three conditions must all hold:

• OpenSSH between 8.5p1 and 9.7p1 (versions before 4.4p1 are affected by the original 2006 flaw unless separately patched)
• glibc-based Linux — Alpine and other musl-based systems are not affected in the same way
• sshd reachable from an untrusted network

Check your version:

sshd -V 2>&1 | head -1

On Debian/Ubuntu:

dpkg -l openssh-server | grep openssh
apt changelog openssh-server | head -20

On RHEL/Rocky/Alma:

rpm -q openssh-server
rpm -q --changelog openssh-server | grep -i 6387 | head

If the changelog references CVE-2024-6387, you're patched regardless of the version banner.

How to fix it

Patch. It's a package update, not a migration:

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade openssh-server
sudo systemctl restart sshd

# RHEL / Rocky / Alma
sudo dnf update openssh-server
sudo systemctl restart sshd

Restarting sshd does not drop existing SSH sessions — new connections use the new binary while your current session continues. Still, keep a second session open while you do it.

If you genuinely cannot patch immediately, the documented mitigation is to disable the login grace timeout in /etc/ssh/sshd_config:

LoginGraceTime 0

This removes the SIGALRM path the exploit depends on. Be aware of the trade-off: unauthenticated connections are no longer timed out, so this makes connection-exhaustion denial of service easier. Treat it as a stopgap, not a resolution.

Reduce the attack surface while you're in there

Worth doing regardless of this specific CVE:

• Don't expose SSH to the whole internet. Restrict to known IPs at the firewall, or put it behind a VPN or bastion host.
• Key-based authentication only — set PasswordAuthentication no.
• PermitRootLogin no, and use sudo from a normal account.
• Fail2ban or CrowdSec to rate-limit and ban brute-force sources.
• Automatic security updates — unattended-upgrades on Debian/Ubuntu — so the next one lands without you.

The wider lesson

regreSSHion is a reminder that a fixed vulnerability can come back. It was patched in 2006 and reintroduced by a refactor in 2021 that removed a guard nobody realised was load-bearing. Regression tests for security fixes matter as much as the original fix — and "we fixed that years ago" is not the same as "it's still fixed."