In July 2024, security researchers at Qualys disclosed a critical vulnerability in OpenSSH — the software used to manage remote access to the vast majority of Linux servers on the internet. The vulnerability, designated CVE-2024-6387 and nicknamed "RegreSSHion," allows an unauthenticated attacker to execute arbitrary code as root on affected systems. It is a signal handler race condition: a subtle class of bug that had been fixed in OpenSSH back in 2006, only to be inadvertently reintroduced in a subsequent release.
This article explains what the vulnerability is, which systems are affected, and what you need to do to protect your infrastructure.
OpenSSH handles login timeouts using a signal called SIGALRM. When a client connects but does not complete authentication within a configurable time limit (LoginGraceTime, default 120 seconds), the server sends itself a SIGALRM to abort the connection. The problem is in how OpenSSH handles this signal.
Signal handlers run asynchronously — they can interrupt the main program at any point. If the SIGALRM fires at exactly the wrong moment, while OpenSSH is in the middle of a non-reentrant function (one that is not safe to interrupt and re-enter), the result is undefined behaviour. Specifically, the vulnerability allows heap memory corruption, which with sufficient manipulation can lead to arbitrary code execution.
The attack is probabilistic, not deterministic. An attacker must typically attempt the race condition thousands of times to succeed. In practice, researchers demonstrated successful exploitation within a few hours of sustained attempts on a standard server — not instant, but well within the capabilities of a motivated attacker. Once successful, the attacker has a root shell with full control of the server.
CVSS Score: 8.1 (High). Unauthenticated remote code execution as root. Any internet-exposed SSH server running a vulnerable version of OpenSSH should be patched immediately.
The vulnerability affects OpenSSH versions 8.5p1 through 9.7p1 on Linux systems using glibc. Specifically:
The most commonly affected systems are Ubuntu, Debian, Red Hat, CentOS, Fedora, and Amazon Linux servers running OpenSSH within the vulnerable version range — which means the majority of internet-facing Linux servers were potentially affected at the time of disclosure.
Run the following command on any Linux server:
This outputs the OpenSSH version. Compare it against the vulnerable range (8.5p1–9.7p1). For most distributions, the faster approach is to check whether a patched package is installed:
The fix was released as OpenSSH 9.8p1, which patches the signal handler to avoid the race condition. Major Linux distributions released patched packages within days of the disclosure.
On Debian/Ubuntu:
On Red Hat/CentOS/Fedora:
After upgrading, restart the SSH service:
Verify the new version is running:
If an immediate upgrade is not possible, two configuration changes reduce risk significantly:
1. Set LoginGraceTime to 0. This disables the timeout-based signal entirely, preventing the vulnerable code path from being triggered. Edit /etc/ssh/sshd_config:
The trade-off is that this disables connection timeout enforcement, which could allow unauthenticated connections to hold connections open indefinitely. This is acceptable if combined with rate limiting at the firewall level.
2. Restrict SSH access by IP. Using firewall rules (iptables, UFW, or cloud security groups) to limit SSH access to known IP addresses significantly reduces exposure. Even if your SSH version is vulnerable, the vulnerability cannot be exploited from an IP address that is blocked at the network level.
RegreSSHion is a regression — a vulnerability that was fixed, then reintroduced by a subsequent change. It had been present in a widely deployed version of OpenSSH for approximately three years before discovery. This illustrates several important security principles.
First, critical infrastructure software requires continuous security review, not one-time auditing. A fix applied in 2006 does not guarantee immunity in 2024 if the codebase evolves.
Second, automatic security updates are valuable for server infrastructure. Organisations that applied distribution security updates promptly were already protected before the public disclosure. Those with manual update policies had a window of exposure.
Third, defence in depth matters. Servers with SSH restricted to known IPs were not exploitable from the internet even when running vulnerable software. Network-level controls buy time when software vulnerabilities are discovered.
For more security guidance, see our article on modern phishing tactics and email authentication with SPF, DKIM and DMARC.