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.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. |
noisgate verdict.
The deciding factor is exploit friction, not impact: this is pre-auth root on paper, but the demonstrated path is a timing-sensitive race that needed sustained attempts and was only publicly proven on 32-bit glibc targets. It stays HIGH because SSH is a common edge service and no credentials are required, but it does not earn CRITICAL without cleaner, repeatable, broad-platform exploitation or KEV-grade evidence.
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.
What to do — in priority order.
- Restrict SSH exposure — Move vulnerable SSH off the public internet where possible, or hard-allowlist source IPs with NGFW, security groups, VPN, or ZTNA controls. For a HIGH verdict, deploy this exposure reduction within 30 days if you cannot patch immediately.
- Prioritize edge and bastion hosts — Treat internet-facing jump boxes, cloud admin nodes, appliance shells, and privileged access gateways as the first mitigation tier because they satisfy the attacker's only hard prerequisite: reachability. For a HIGH verdict, finish this prioritization and shielding within 30 days.
- Use vendor backports, not banner guesses — Validate package state from the OS vendor instead of assuming every
OpenSSH_8.xor9.2p1banner 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. - Watch for pre-auth churn — Alert on unusual waves of failed or incomplete SSH sessions, repeated grace-time expirations, and distributed connection spray against the same host. This will not stop the bug, but it gives you visibility while patching and should be enabled 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.
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"If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.