This is a jammed front-door lock that only sometimes pops open, but it opens straight into the master key room
This plugin is tracking CVE-2024-6387 (regreSSHion), a signal-handler race in sshd that can let an unauthenticated attacker hit memory-unsafe code when LoginGraceTime expires. The upstream affected range is Portable OpenSSH 8.5p1 through 9.7p1 inclusive, plus versions earlier than 4.4p1 if they were never backport-patched for the older 2006/2008 fixes; OpenSSH 9.8p1 contains the upstream fix. The practical blast radius is mostly glibc-based Linux SSH servers; OpenBSD is explicitly not vulnerable.
The vendor's HIGH label is broadly fair, but the raw RCE headline overstates how often this turns into a real breach in modern enterprise fleets. The big friction is that public exploitability has been shown under lab conditions on 32-bit glibc targets with long, repeated timing attempts, while 64-bit exploitation was believed possible but not publicly demonstrated in the primary advisory. That said, this is still pre-auth remote root on a ubiquitous edge service, so I would trim the score down from 8.1, not bury it in backlog.
4 steps from start to impact.
Reach an exposed sshd
sshd. The most realistic entry point is an internet-facing bastion, admin gateway, appliance shell, or cloud VM with SSH exposed beyond a tightly scoped management network.- Target runs vulnerable OpenSSH server code
- Attacker can reach the SSH service over the network
- The service is not isolated behind VPN, ZTNA, or strict source-IP allowlists
- A large share of enterprise SSH is internal-only, not internet-exposed
- Well-run fleets already pin SSH to jump hosts or management networks
- External exposure is easy to inventory and usually small compared with total Linux population
Win the race with a PoC like 7etsuo-regreSSHion.c
LoginGraceTime expiry. Public PoCs exist, but primary vendor-side testing from Palo Alto Unit 42 said the PoC they tested did not achieve RCE in their environment.- Target is in the vulnerable code path
- Attacker can sustain repeated connection attempts over time
- Memory layout and timing are favorable enough to hit the race
- This is a high-complexity race condition, not a clean one-shot exploit
- OpenSSH upstream documented roughly 10,000 attempts on average and 6-8 hours under lab conditions on proven 32-bit targets
- Default connection throttling, network controls, and noisy retry behavior make this operationally ugly
Overcome platform assumptions
- Target platform matches a workable exploit recipe
- The attacker knows or can infer distro/libc/runtime details
- Downstream patches or backports have not already fixed the issue
- Most enterprise Linux server estates are overwhelmingly 64-bit
- Backported vendor fixes mean banner strings alone are unreliable
- ASLR behavior and distro-specific heap details narrow exploit portability
Land root in sshd context
- Prior race steps succeed
- Host controls do not kill the daemon or block post-exploit actions
- There is no credential requirement, but getting here is the hard part
- Post-exploit activity is where EDR, auditd, and behavior analytics should light up
sshd, and root-level post-exploitation behavior are the detection layer that matters.OpenSSH_8.x or 9.2p1 banner is vulnerable. Backported Debian/Ubuntu/RHEL fixes change patch status without changing the upstream-looking banner, and that validation should be part of mitigation within 30 days.MFAfor SSH does not stop this, because the flaw is pre-authentication.Key-only authenticationdoes not remove the vulnerable code path before auth timeout handling.Changing the SSH portonly cuts commodity noise; it does not materially block a targeted scan.Fail2banalone is weak here because a distributed attacker can rotate source IPs and play a long timing game.
The supporting signals.
| In-the-wild status | No authoritative public campaign evidence in the primary sources I reviewed. Unit 42 said there was *no known activity in the wild* as of 2024-07-02; later third-party aggregators are noisier, so treat any "exploited" claims as low-confidence unless you have your own telemetry. |
|---|---|
| PoC availability | Yes, public PoCs exist. NVD references GitHub PoCs, and third-party tracking pages point to repos such as acrono/cve-2024-6387-poc and similar forks. That matters for copycat activity, but Unit 42 reported the PoC they tested did not achieve RCE in their environment. |
| EPSS | Directional only: Feedly's CVE page currently shows EPSS 64.05%. I did not query FIRST's live API directly in this review, so use that as a rough signal, not a hard planning number. |
| KEV status | Not KEV-listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-02-10. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H from NVD. Translation: unauthenticated network reachability with high attack complexity and full-root impact if you win the race. |
| Affected versions | Upstream says Portable OpenSSH 8.5p1-9.7p1 inclusive are affected, plus <4.4p1 if older fixes were never backported. OpenSSH 9.8 release notes also note the practical exploit research was on 32-bit Linux/glibc and that OpenBSD is not vulnerable. |
| Fixed versions | Upstream fix is 9.8p1. Official distro backports matter more than the upstream major/minor: Ubuntu lists 22.04: 1:8.9p1-3ubuntu0.10, 23.10: 1:9.3p1-1ubuntu3.6, 24.04: 1:9.6p1-3ubuntu13.3; Debian tracks fixes such as bullseye 1:8.4p1-5+deb11u5 and bookworm 1:9.2p1-2+deb12u5. |
| Exposure data | Unit 42 observed 2,173,896 exposed vulnerable IPs in the United States alone on 2024-07-01. Censys published ready-made queries for public-facing OpenSSH and explicitly notes version/banner filtering pitfalls around patched Debian/Ubuntu builds. |
| Disclosure date | 2024-07-01. OpenSSH 9.8/9.8p1 and the Qualys advisory landed the same day. |
| Reporter | Reported by the Qualys Security Advisory Team / Qualys TRU and acknowledged in the OpenSSH release notes. |
Sources.
Why this verdict
- Down from 8.1: exploitation is a race condition with high attack complexity, not a deterministic one-request RCE.
- Further down: the primary demonstrated exploit path was 32-bit glibc; most enterprise server estates are 64-bit, and upstream said 64-bit exploitation was believed possible but not publicly demonstrated at disclosure.
- Still HIGH: this is unauthenticated remote root on
sshd, one of the most common administrative services exposed at network edges. - Still HIGH: public PoCs and massive exposed population mean attackers will keep iterating even if first-generation PoCs are shaky.
- Not lower: the prerequisite is only network reachability, not prior compromise, auth, or a special role.
Why not higher?
It is not CRITICAL because the real-world chain is fragile. The need for repeated timing attempts, platform-specific behavior, and the lack of strong authoritative in-the-wild evidence all push this below the "drop-everything" bucket.
Why not lower?
It is not MEDIUM because a successful exploit is still a pre-auth root compromise of a service that often sits on admin perimeters. Even hard-to-exploit bugs deserve elevated handling when they target SSH and require no credentials.
Crowdsourced verification payload.
Run this on the target Linux host as a local audit check: sudo bash check_cve_2024_6387.sh. Root is preferred because package and changelog checks are more reliable, but the script will still attempt a best-effort result without it.
#!/usr/bin/env bash
# check_cve_2024_6387.sh
# Detect likely exposure to CVE-2024-6387 (regreSSHion) on Linux hosts.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
status_unknown() {
echo "UNKNOWN: $1"
exit 2
}
status_vuln() {
echo "VULNERABLE: $1"
exit 1
}
status_patched() {
echo "PATCHED: $1"
exit 0
}
have_cmd() {
command -v "$1" >/dev/null 2>&1
}
get_os_field() {
local key="$1"
[ -r /etc/os-release ] || return 1
awk -F= -v k="$key" '$1==k {gsub(/^"|"$/, "", $2); print $2}' /etc/os-release
}
ver_ge() {
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}
ver_lt() {
[ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}
normalize_openssh_ver() {
# Input examples:
# OpenSSH_9.2p1 Debian-2+deb12u5, OpenSSH_8.7p1, OpenSSH_9.6p1 Ubuntu-3ubuntu13.3
local raw="$1"
raw="${raw#OpenSSH_}"
raw="${raw%% *}"
raw="${raw%%,*}"
echo "$raw"
}
get_sshd_version() {
local out=""
if have_cmd sshd; then
out="$(sshd -V 2>&1 | head -n1 || true)"
if [ -n "$out" ]; then
normalize_openssh_ver "$out"
return 0
fi
fi
if have_cmd ssh; then
out="$(ssh -V 2>&1 | head -n1 || true)"
if [ -n "$out" ]; then
normalize_openssh_ver "$out"
return 0
fi
fi
return 1
}
# 1) Prefer Debian/Ubuntu package-level checks because backports matter.
if have_cmd dpkg-query; then
if dpkg-query -W -f='${Status}' openssh-server 2>/dev/null | grep -q 'install ok installed'; then
pkg_ver="$(dpkg-query -W -f='${Version}' openssh-server 2>/dev/null)"
os_id="$(get_os_field ID || true)"
codename="$(get_os_field VERSION_CODENAME || true)"
case "$os_id:$codename" in
ubuntu:focal|ubuntu:bionic|ubuntu:xenial|ubuntu:trusty)
status_patched "Ubuntu $codename is marked not affected by vendor advisory ($pkg_ver)"
;;
ubuntu:jammy)
if dpkg --compare-versions "$pkg_ver" ge '1:8.9p1-3ubuntu0.10'; then
status_patched "Ubuntu Jammy package fixed ($pkg_ver)"
else
status_vuln "Ubuntu Jammy package predates fixed build ($pkg_ver)"
fi
;;
ubuntu:mantic)
if dpkg --compare-versions "$pkg_ver" ge '1:9.3p1-1ubuntu3.6'; then
status_patched "Ubuntu Mantic package fixed ($pkg_ver)"
else
status_vuln "Ubuntu Mantic package predates fixed build ($pkg_ver)"
fi
;;
ubuntu:noble)
if dpkg --compare-versions "$pkg_ver" ge '1:9.6p1-3ubuntu13.3'; then
status_patched "Ubuntu Noble package fixed ($pkg_ver)"
else
status_vuln "Ubuntu Noble package predates fixed build ($pkg_ver)"
fi
;;
debian:bullseye)
if dpkg --compare-versions "$pkg_ver" ge '1:8.4p1-5+deb11u5'; then
status_patched "Debian Bullseye package fixed ($pkg_ver)"
else
status_vuln "Debian Bullseye package predates fixed build ($pkg_ver)"
fi
;;
debian:bookworm)
if dpkg --compare-versions "$pkg_ver" ge '1:9.2p1-2+deb12u5'; then
status_patched "Debian Bookworm package fixed ($pkg_ver)"
else
status_vuln "Debian Bookworm package predates fixed build ($pkg_ver)"
fi
;;
esac
fi
fi
# 2) RPM-family heuristic: changelog/backport check first, then version fallback.
if have_cmd rpm; then
if rpm -q openssh-server >/dev/null 2>&1; then
rpm_nvra="$(rpm -q openssh-server 2>/dev/null || true)"
if rpm -q --changelog openssh-server 2>/dev/null | grep -q 'CVE-2024-6387'; then
status_patched "RPM changelog indicates vendor fix for CVE-2024-6387 ($rpm_nvra)"
fi
fi
fi
# 3) Generic upstream-version fallback for portable/non-backported builds.
if ver="$(get_sshd_version)"; then
if ver_lt "$ver" '4.4p1'; then
status_vuln "OpenSSH version older than 4.4p1 ($ver); treat as vulnerable unless vendor explicitly backported old fixes"
fi
if ver_ge "$ver" '8.5p1' && ver_lt "$ver" '9.8p1'; then
status_vuln "OpenSSH version is in upstream affected range 8.5p1-9.7p1 ($ver)"
fi
if ver_ge "$ver" '4.4p1' && ver_lt "$ver" '8.5p1'; then
status_patched "OpenSSH version falls in upstream non-affected range 4.4p1-8.4p1 ($ver)"
fi
if ver_ge "$ver" '9.8p1'; then
status_patched "OpenSSH version is at or above upstream fixed release 9.8p1 ($ver)"
fi
fi
status_unknown "Could not determine vulnerable package or OpenSSH version reliably"