← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:201194 · CWE-364 · Disclosed 2024-07-01

OpenSSH < 9

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Hard to weaponize at scale, but pre-auth root on exposed SSH is still a HIGH-priority patch."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach an exposed sshd

The attacker needs network reachability to TCP/22 on a host running a vulnerable 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External attack-surface tools and vuln scanners have good coverage for banner/version discovery, but distro backports can create false positives if you only key off upstream version strings.
STEP 02

Win the race with a PoC like 7etsuo-regreSSHion.c

The attacker then has to trigger the SIGALRM race during authentication timeout handling, typically by opening many connections and repeatedly forcing 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for abnormal SSH pre-auth churn: many incomplete sessions, repeated grace-time expirations, and sustained connection pressure from rotating sources. Network IDS and auth logs see the noise even if they do not understand the race.
STEP 03

Overcome platform assumptions

The exploit path that was actually demonstrated targeted 32-bit Linux/glibc with ASLR. Upstream explicitly said 64-bit exploitation was thought possible but had not been demonstrated at disclosure time, and non-glibc paths were only considered conceivable.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Asset inventory and package-state inspection beat banner matching here. Good EDR/SBOM/package telemetry can sharply reduce false positives.
STEP 04

Land root in sshd context

If the race is won, the attacker gets code execution with root privileges in the SSH daemon path before authentication. That is full host compromise, with immediate credential theft, persistence, and lateral movement options.
Conditions required:
  • Prior race steps succeed
  • Host controls do not kill the daemon or block post-exploit actions
Where this breaks in practice:
  • 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
Detection/coverage: Vuln scanners stop helping once exploitation starts. Host telemetry, process ancestry, unexpected child processes from sshd, and root-level post-exploitation behavior are the detection layer that matters.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityYes, 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.
EPSSDirectional 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 statusNot KEV-listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-02-10.
CVSS vectorCVSS: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 versionsUpstream 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 versionsUpstream 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 dataUnit 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 date2024-07-01. OpenSSH 9.8/9.8p1 and the Qualys advisory landed the same day.
ReporterReported by the Qualys Security Advisory Team / Qualys TRU and acknowledged in the OpenSSH release notes.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.2/10)

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.

HIGH Affected-version and fixed-version mapping
MEDIUM Real-world exploitability across typical 64-bit enterprise Linux fleets
MEDIUM Current in-the-wild exploitation status

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Use vendor backports, not banner guesses — Validate package state from the OS vendor instead of assuming every 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.
  4. 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.
What doesn't work
  • MFA for SSH does not stop this, because the flaw is pre-authentication.
  • Key-only authentication does not remove the vulnerable code path before auth timeout handling.
  • Changing the SSH port only cuts commodity noise; it does not materially block a targeted scan.
  • Fail2ban alone is weak here because a distributed attacker can rotate source IPs and play a long timing game.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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"
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, separate public-facing SSH from everything else: identify internet-reachable bastions, admin gateways, and cloud VMs first, verify whether distro backports already fixed them, and put source-IP restrictions or VPN/ZTNA controls in front of any still-vulnerable edge host while patching. Because this lands as HIGH and I found no authoritative KEV-grade exploitation evidence, the noisgate mitigation SLA is ≤ 30 days and the noisgate remediation SLA is ≤ 180 days; in practice, patch exposed SSH first this cycle, then close the rest through normal Linux server maintenance instead of emergency-wide fleet disruption.

Sources

  1. OpenSSH release notes
  2. Qualys advisory: regreSSHion
  3. NVD CVE-2024-6387
  4. Ubuntu security tracker for CVE-2024-6387
  5. Debian security tracker for CVE-2024-6387
  6. Palo Alto Unit 42 threat brief
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Feedly CVE page
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.