CVE-2024-6387 (regreSSHion): the OpenSSH signal-handler race

02Which versions are affected?

Exposure is a window, not a cut-off. Very old releases are vulnerable, a long middle band is safe, and the recent band before the fix is vulnerable again.

03How does an attack work, conceptually?

The attacker opens many connections and simply waits, never authenticating, so that each one's LoginGraceTime expires and fires SIGALRM. The goal is to have the alarm land precisely while sshd is inside a memory operation, leaving allocator state that the handler then corrupts. It is a probabilistic race: Qualys reported roughly 10,000 attempts on average to win it.

That difficulty is the whole story of this bug's real-world risk. A working demonstration needed 6–8 hours of continuous connections against a 32-bit target with ASLR, and exploitation on 64-bit systems was believed possible but not shown. There is no single magic packet. What a defender should take from this is that limiting how fast an attacker can open unauthenticated connections directly lengthens the time an attack needs.

04How to check if you are affected

Read the banner version and the installed package version. The upstream version alone can mislead you, because distributions back-port the fix without changing the leading number — a Debian box can report 9.2p1 and still be patched.

# Upstream version string
ssh -V            # e.g. OpenSSH_9.2p1 Debian-2+deb12u10 ...
sshd -V 2>&1 | head -1

# The package build is what tells you whether the fix is in
dpkg-query -W -f='${Package} ${Version}\n' openssh-server   # Debian/Ubuntu
rpm -q openssh-server                                        # RHEL/Fedora/SUSE

# Confirm the running daemon was restarted after the upgrade
systemctl status ssh 2>/dev/null || systemctl status sshd

# Detection: count pre-auth timeouts in the last hour (unit is sshd on RHEL)
journalctl -u ssh --since "-1h" -o cat | grep -c 'Timeout before authentication'

05How to fix it: patched versions

Upstream fixed the race in OpenSSH 9.8/9.8p1 on 1 July 2024 by moving the unsafe work out of the signal handler and into the listener process. Distributions shipped back-ports the same day or shortly after. Install the vendor update for your platform and restart the service.

06Mitigations if you cannot patch yet

If you genuinely cannot update immediately, Qualys and Red Hat documented a configuration mitigation: set LoginGraceTime to 0. This removes the timeout whose expiry fires the dangerous signal, closing the remote-code-execution path. The trade-off is explicit — with no grace timeout, an attacker can hold all MaxStartups slots open and cause a denial of service instead. You are trading a possible remote root for a possible lockout.

The more durable mitigation is to stop exposing SSH to the whole internet, as set out in hardening port 22. Most servers have no reason to accept SSH from arbitrary addresses, and reducing exposure shrinks both this bug's surface and the brute-force noise that comes with it. Pair that with sensible connection limits so an attacker cannot open unauthenticated sessions quickly, which is exactly what this race needs.

• Restrict SSH to a management network, VPN or a short allow-list of addresses rather than the public internet
• Lower MaxStartups and PerSourceMaxStartups so unauthenticated connections cannot be opened in bulk
• Watch the auth log for the "Timeout before authentication" message spiking from many sources
• Run a log-watching tool such as fail2ban alongside a host firewall, as Red Hat suggests with the config mitigation

# 1) /etc/ssh/sshd_config.d/10-cve-2024-6387.conf  (check: sshd -t)
# Trade-off: removes the RCE path but allows a MaxStartups DoS.
LoginGraceTime 0
MaxStartups 10:30:60
PerSourceMaxStartups 3

# 2) ssh-allowlist.nft: only named admin ranges may reach port 22.
#    Check with: nft -c -f ssh-allowlist.nft  Load with: nft -f ssh-allowlist.nft
#    IPv6 clients are dropped too unless you add an ipv6_addr set.
table inet ssh_allowlist {
  set admin_v4 {
    type ipv4_addr; flags interval;
    elements = { 198.51.100.0/24, 203.0.113.10 }
  }
  chain input {
    type filter hook input priority filter - 10; policy accept;
    tcp dport 22 ip saddr @admin_v4 accept
    tcp dport 22 drop
  }
}

07What a reverse proxy or WAF can and cannot do

Be honest about this one: SSH is not HTTP, so a web application firewall does nothing for it. A reverse proxy that terminates HTTP, and the WAF in front of it, protect your website and APIs — they never see the SSH port, and CVE-2024-6387 lives entirely in sshd. No edge rule can filter this, so virtual patching has nothing to offer here.

What edge infrastructure does help with is keeping your origin's real address out of public view. If your website sits behind a proxy and your origin IP is hidden, an attacker targeting your site cannot easily map it to the server behind it. Internet-wide scanners sweep every IPv4 address regardless, though, so an sshd listening on the open internet will still be found — which is why the firewall allow-list above matters more, and why none of this substitutes for installing the patch.

08Disclosure timeline

For scale, Qualys counted over 14 million potentially vulnerable OpenSSH servers exposed to the internet using Censys and Shodan, and about 700,000 vulnerable internet-facing instances — 31% of internet-facing OpenSSH — in its own customer base. The inventory you would build when preparing to stop a DDoS attack, listing every service reachable from the internet, is also the quickest way to confirm nothing exposes SSH that should not.