CVE-2024-6387 regreSSHion, The OpenSSH sshd regression that turns a timeout into an incident

Why CVE-2024-6387 matters, even if you think your SSH is boring

Most security teams don’t treat “SSH timeouts” as an emergency. They treat them as background noise: brute-force, scanners, misconfigured clients, and the occasional confused automation. CVE-2024-6387 changes that mental model.

This CVE is a security regression in OpenSSH’s server daemon, sshd, where a race condition can lead to unsafe signal handling, and a remote unauthenticated attacker may be able to trigger it by simply failing to authenticate within a time period. (NVD) That reads almost too plain, but the operational consequence is not: sshd is frequently the control plane for fleets, bastions, network appliances, CI runners, data pipelines, and your “break glass” access when everything else is down.

Upstream OpenSSH describes the bug as a critical vulnerability in Portable OpenSSH versions 8.5p1 through 9.7p1 that may allow arbitrary code execution with root privileges. It also states that successful exploitation was demonstrated on 32-bit Linux/glibc systems with ASLR, and under lab conditions the attack took 6–8 hours on average of continuous connections, while 64-bit exploitation was believed possible but not demonstrated at the time of release. (OpenSSH)

Ubuntu’s coordinated release write-up frames the practical risk plainly: it’s unauthenticated, network-exploitable RCE en sshd affecting OpenSSH starting with 8.5p1 and before 9.8p1, disclosed by Qualys and fixed as part of a coordinated release date. (Ubuntu)

The takeaway is not “panic.” The takeaway is “treat this like an outage-class vulnerability” because the affected component is a hinge. Even a difficult exploit can be worth trying when the payoff is remote pre-auth code execution on a widely deployed service.

One-page incident summary you can paste into a ticket

What it is

CVE-2024-6387 is a regression in OpenSSH sshd where a race condition during signal handling may lead to unsafe behavior and potential pre-auth compromise. (NVD)

Who is affected

Upstream states Portable OpenSSH 8.5p1–9.7p1 inclusive may be vulnerable; OpenSSH 9.8 includes the fix. (OpenSSH) Ubuntu’s advisory similarly describes impact for versions 8.5p1 up to but not including 9.8p1. (Ubuntu)

What makes it dangerous

It’s pre-auth on a control-plane service. Exploitation has been demonstrated in lab on 32-bit Linux/glibc with ASLR, with hours-long attack windows under lab conditions. (OpenSSH)

Fix

Upgrade to a vendor-patched package or OpenSSH 9.8 or later (or the distribution’s backported fix). (OpenSSH)

Temporary mitigation if you cannot patch immediately

Establecer LoginGraceTime 0 to avoid the timeout path that triggers the vulnerable signal handler behavior, but do it with compensating controls because it changes resource-exhaustion dynamics. (Check Point Blog)

The keywords people actually use when they search this incident

If you search CVE-2024-6387 today, you’ll notice that the most visible vendor and research write-ups converge on a consistent vocabulary:

• regreSSHion as the nickname and anchor term, used prominently by Ubuntu, Qualys, and others (Ubuntu)
• OpenSSH RCE o sshd RCE as the high-intent click phrase (OpenSSH)
• LoginGraceTime y SIGALRM because the trigger is tied to the authentication grace timeout and its alarm signal path (NVD)
• glibc 32-bit y ASLR because upstream explicitly calls out successful demonstration on that platform class (OpenSSH)
• OpenSSH 9.8p1 because it’s the release line that contains the fix and additional hardening changes (OpenSSH)

This matters for your own incident comms. If your internal ticket says “signal-handler race condition,” many stakeholders won’t connect it to the flood of external guidance. If it says “CVE-2024-6387 regreSSHion,” it will.

What’s actually happening under the hood, without exploit instructions

At a high level, the incident sits at the intersection of three facts:

1. sshd uses a grace period for pre-auth connections. If the client doesn’t authenticate within that window, the server triggers a cleanup path. (NVD)
2. That timeout path is implemented using a signal alarm mechanism. Signals are asynchronous: they can interrupt code at almost any point. (NVD)
3. In the vulnerable versions, the signal handler can call functions that are not safe to call from within a signal handler context, which can lead to inconsistent internal state and memory hazards. Multiple write-ups highlight this “non-async-signal-safe” property and point at logging paths as part of the problem framing. (Seguridad Oligo)

Upstream’s 9.8 release notes do not present “how to exploit it.” They present what defenders need to know: it can reach root code execution in principle, exploitation has been demonstrated in a specific environment class, it is time-consuming under lab conditions, and the attacks may improve now that the details are public. (OpenSSH)

That last clause is the reason you patch. The attacker’s cost curve tends to improve over time. Your patching cost curve tends to get worse over time because change windows fill up and attention shifts.

Severity, exploitability, and why CVSS doesn’t decide your priority

You will see CVSS cited as 8.1 in some coverage. (Check Point Blog) But treat CVSS as a sorting hint, not a decision.

The operational priority comes from:

• Pre-auth surface: there is no credential requirement to hit the vulnerable behavior path. (NVD)
• Control-plane placement: SSH is often the management plane for servers, appliances, and cloud workloads. A compromise here is a pivot point.
• Exposure reality: many organizations still have Internet-exposed port 22 on bastions, appliances, or legacy servers.
• Patch clarity: upstream and major distros provide crisp fix guidance, and OpenSSH 9.8 is a clean line in the sand. (OpenSSH)

It’s also important to separate “hard to exploit” from “not worth attempting.” Upstream explicitly calls out that exploitation is believed possible on 64-bit but wasn’t demonstrated at release time and warns that attacks will likely be improved. (OpenSSH) That’s not hand-waving; it’s how exploit development typically evolves once the primitives are public.

Affected versions, and the most common trap, backports and misleading banners

Upstream version window

OpenSSH states the critical sshd race condition affects Portable OpenSSH 8.5p1 through 9.7p1 inclusive, fixed in OpenSSH 9.8. (OpenSSH)

Qualys and Ubuntu both describe the regression as introduced around OpenSSH 8.5p1 and affecting versions before 9.8p1 in common Linux deployments. (Ubuntu)

“My banner says 9.7p1 so I’m doomed” is not a reliable conclusion

In real environments, many distributions backport patches without changing the upstream version string in obvious ways. That means:

• A vulnerable-looking version number may already be patched by the vendor.
• A “safe-looking” version number might be customized in ways that change behavior.

Your authoritative truth should be the vendor advisory for your exact distro release and the package build that includes the fix, not only the exposed SSH banner. Ubuntu publishes a CVE page and coordinated release guidance that is meant to be consumed this way. (Ubuntu) Red Hat similarly tracks the CVE in its portal. (Red Hat Customer Portal)

OpenBSD note

OpenSSH upstream explicitly states OpenBSD is not vulnerable. (OpenSSH) That does not automatically mean “all BSDs are safe,” but it is a meaningful signal for prioritization: the “portable” Linux/glibc attack surface is where the discussion has concentrated.

The related CVE you should not ignore, CVE-2024-6409

CVE-2024-6387 is not the only race-condition story in this window. CVE-2024-6409 is a related signal-handling race condition issue described in public discussions, with emphasis on behavior in certain versions and the impact of downstream patches. (Openwall)

The oss-security thread is particularly useful for defenders because it states two practical points:

• LoginGraceTime 0 is a mitigation that works against both issues. (Openwall)
• Another mitigation sometimes discussed as “-e” does no fully mitigate CVE-2024-6409, meaning you can end up with a false sense of closure if you only treat CVE-2024-6387 as the whole story. (Openwall)

If you are building a remediation plan, treat “upgrade OpenSSH package to a vendor-fixed build” as the durable outcome, and treat config-only mitigations as short-lived stopgaps.

Your reality check, is this actually being exploited in the wild

A lot of internet copy repeats the same sentence: “actively exploited.” Don’t accept that as truth without checking authoritative feeds.

• Upstream says exploitation has been demonstrated under lab conditions, and warns attacks may improve, but does not claim broad in-the-wild exploitation. (OpenSSH)
• A major vendor research write-up in early July 2024 stated no exploitation had been seen to date at that time, while still recommending urgent patching because the exploit is complex but plausible. (Check Point Blog)

If you use CISA KEV as a forcing function, verify with an accessible authoritative data source rather than screenshots. The official KEV dataset mirrored on GitHub shows its catalog version and release date; in the 2026.03.05 catalog snapshot, CVE-2024-6387 is not present in the data file. (GitHub)

The practical posture is the same either way: patch. But your communications should not claim “known exploited” unless your sources support it.

Fast triage workflow, from exposure to proof

This is the workflow that keeps teams sane:

1. Exposure inventory: which hosts have port 22 reachable from untrusted networks
2. Authoritative package check: which hosts run a vulnerable build as defined by the distro advisory
3. Config and compensating controls: what is your current LoginGraceTime, MaxStartups, auth methods
4. Patch rollout: staged, with rollback and break-glass access
5. Verification evidence: command output and package versions captured for audit
6. Post-patch hardening: reduce the blast radius of the next regression

Step 1, enumerate Internet-exposed SSH reliably

Network scanning is a starting point, not a conclusion. Use it to build a candidate list.

# Basic discovery: list hosts with port 22 open and attempt version detection
nmap -p 22 -sV --version-intensity 5 -oG ssh_hosts.gnmap <YOUR_CIDR>

# Extract IPs with 22/open
awk '/22\\/open/{print $2}' ssh_hosts.gnmap | sort -u > ssh_hosts.txt

If you can, run discovery from multiple vantage points: outside-in for true Internet exposure, and inside-out for lateral exposure.

Step 2, determine the server package version, not the client version

A common mistake is checking ssh -V and thinking you’ve checked the server. That checks the client binary.

On Debian/Ubuntu:

dpkg -l | grep -E '^ii\\s+openssh-server\\s' || true
apt-cache policy openssh-server | sed -n '1,20p'

On RHEL/CentOS/Fedora:

rpm -q openssh-server
dnf info openssh-server | sed -n '1,40p'

On Alpine:

apk info -v | grep -E '^openssh-server-' || true

Then cross-check against your vendor’s CVE page or security notice for whether that build includes the fix. Ubuntu’s CVE entry is explicitly written to support this kind of validation. (Ubuntu) Red Hat provides CVE tracking in its portal as well. (Red Hat Customer Portal)

Step 3, inspect relevant sshd settings

You want the effective config, not just file fragments.

# show the effective configuration that sshd would use
# note: may require appropriate privileges depending on your system
sshd -T 2>/dev/null | egrep -i 'logingracetime|maxstartups|passwordauthentication|permitrootlogin|pubkeyauthentication|listenaddress|port' || true

Si sshd -T is restricted in your environment, fall back to reading /etc/ssh/sshd_config and included snippets under /etc/ssh/sshd_config.d/.

Step 4, capture “proof of remediation” as an artifact

Create a simple evidence bundle so you don’t relitigate the incident next quarter.

HOST="$(hostname -f 2>/dev/null || hostname)"
TS="$(date -u +%Y%m%dT%H%M%SZ)"

mkdir -p "/var/tmp/ssh_cve_2024_6387_$TS" || exit 1
OUT="/var/tmp/ssh_cve_2024_6387_$TS"

{
  echo "host=$HOST"
  echo "time_utc=$TS"
  echo "=== package ==="
  (dpkg -l | grep -E '^ii\\s+openssh-server\\s' || rpm -q openssh-server || apk info -v | grep -E '^openssh-server-' || true)
  echo "=== sshd effective config ==="
  (sshd -T 2>/dev/null | egrep -i 'logingracetime|maxstartups|passwordauthentication|permitrootlogin|pubkeyauthentication|port|listenaddress' || true)
  echo "=== systemd unit ==="
  (systemctl status sshd --no-pager 2>/dev/null || systemctl status ssh --no-pager 2>/dev/null || true)
} | tee "$OUT/evidence.txt"

This is boring, which is exactly what you want in an incident response workflow.

Patching guidance, what “fixed” actually means

The clean upstream line

Upstream OpenSSH 9.8 includes fixes for the critical race condition and also includes other security-related changes and operational hardening, such as PerSourcePenalties that penalize repeated failed auth or repeated unauthenticated connections and can temporarily refuse connections from abusive sources. (OpenSSH)

That matters because CVE-2024-6387 is triggered by repeated pre-auth connections. Anything that makes abusive pre-auth behavior harder is operationally helpful, even after you patch.

Vendor patches and coordinated releases

Ubuntu states it released a fix as part of a coordinated release date on July 1, 2024 and describes the vulnerable window as 8.5p1 through before 9.8p1. (Ubuntu)

Qualys also publishes affected version guidance and stresses the regression nature from CVE-2006-5051. (Qualys)

The right way to phrase “patched” in your internal documentation is:

• Parcheado means your installed package contains the vendor’s fix for CVE-2024-6387, not merely that your banner changed.
• Verified means you have recorded the package build version and change record that corresponds to the vendor fix, plus restart confirmation.

Avoid locking yourself out during the rollout

If you operate bastions or remote-only infrastructure:

• Ensure you have at least one out-of-band path (cloud serial console, hypervisor console, management plane VPN, or a break-glass bastion) before restarting SSH.
• Keep an existing SSH session open while applying changes.
• Validar sshd -t before reload/restart.

# Validate configuration syntax before restart
sshd -t

# Prefer reload where possible
systemctl reload sshd 2>/dev/null || systemctl reload ssh 2>/dev/null || true

# If reload is not supported, restart
systemctl restart sshd 2>/dev/null || systemctl restart ssh 2>/dev/null || true

Temporary mitigations when you cannot patch immediately, with honest trade-offs

Several write-ups recommend setting LoginGraceTime a 0 as a mitigation to prevent the timeout path from triggering in the vulnerable way. (Check Point Blog)

However, don’t treat it as a free lunch. Setting LoginGraceTime 0 means unauthenticated sessions can persist longer, which can change your DoS exposure. You mitigate that by combining it with connection limiting y authentication policy hardening.

Mitigation decision table

Mitigación	What it tries to accomplish	What it breaks or changes	When to use
Patch to vendor-fixed OpenSSH build	Removes the vulnerability	Requires change window, restart	Always, primary fix
LoginGraceTime 0	Avoids the timeout-triggered signal path	Can increase resource pressure from hanging pre-auth sessions	Short-term stopgap if patch is delayed (Check Point Blog)
Tighten MaxStartups	Reduces concurrent unauthenticated connection pressure	Can block legitimate bursts behind NAT	Pair with LoginGraceTime 0 during emergency
Firewall rate limiting on port 22	Blunts brute-force and connection floods	May block legitimate automation if mis-tuned	Useful immediately, especially for Internet-exposed hosts
Restrict exposure to known IP ranges	Removes the public attack surface	Requires network change, may impact operations	Best practice for bastions

Example sshd_config emergency profile

This is not a “perfect” profile. It’s a practical “buy time” profile you can deploy while you schedule patching.

# Emergency mitigation profile for Internet-exposed SSH
# Apply carefully, test in staging, and ensure break-glass access.

LoginGraceTime 0
MaxAuthTries 3
MaxStartups 10:30:60

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Notice what’s missing: anything that claims to “detect exploitation.” For this CVE, your defensive win condition is patching and reducing exposure.

Firewall example, nftables rate limiting

# Example only, tune for your environment
nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname lo accept

# Allow SSH with rate limiting
nft add rule inet filter input tcp dport 22 ct state new limit rate 30/minute accept
nft add rule inet filter input tcp dport 22 drop

If you already use a cloud firewall, implement rate limits there to reduce host-level overhead.

Monitoring and detection, what you can see without chasing ghosts

CVE-2024-6387 is not a clean “signature in logs.” But you can still improve your visibility:

• spikes in new SSH connections
• repeated unauthenticated connection attempts that linger
• abnormal sshd crashes or restarts
• increased “timeout before authentication” patterns

OpenSSH 9.8’s PerSourcePenalties feature is specifically designed to penalize repeated failed auth and repeated connections that never complete authentication. (OpenSSH) That is a nice hardening layer even after the CVE is patched.

Splunk example queries

# 1) New connections to sshd per source IP, time-bucketed
index=linux sourcetype=sshd ("Connection from" OR "Accepted" OR "Failed" OR "timeout before authentication")
| timechart span=5m count by src_ip limit=20

# 2) Timeouts before authentication
index=linux sourcetype=sshd "timeout before authentication"
| stats count by host, src_ip
| sort -count

Elastic / KQL style query hints

# Match common sshd timeout wording
event.dataset: "sshd" and message: ("timeout before authentication" or "Connection closed by authenticating user")

These are not proofs of exploitation. They are triggers for triage: “is this host Internet-exposed, is it unpatched, is it under pressure.”

Long-term SSH hardening, making the next regression less dramatic

Treat this incident as a forcing function to implement “boring but resilient” SSH posture:

1. Reduce exposure: only expose port 22 where it is truly needed, and prefer VPN or ZTNA for admin access.
2. Prefer keys and hardware-backed auth: disable password auth wherever possible.
3. Disable root login and minimize privileged paths: enforce privilege separation and audited escalation.
4. Constrain forwarding: disable agent forwarding and TCP forwarding unless explicitly required.
5. Use modern OpenSSH features: newer releases include operational hardening such as PerSourcePenalties. (OpenSSH)

A practical baseline snippet

# Baseline hardening
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Visibility
LogLevel VERBOSE

# Resource pressure controls
MaxAuthTries 3
MaxStartups 10:30:60

If you can’t disable forwarding globally, constrain it to specific groups using Match bloques.

Related CVEs that commonly show up in the same SSH security program

A mature SSH security program doesn’t treat CVE-2024-6387 in isolation. Here are the ones that repeatedly surface in real-world governance cycles:

CVE-2024-6409, related signal-handling race condition

NVD describes CVE-2024-6409 as a race condition involving unsafe signal handling and non-async-signal-safe calls, similar in theme to CVE-2024-6387. (NVD) The oss-security thread explains practical differences and why mitigation choices matter. (Openwall)

CVE-2023-48795, the Terrapin attack family

This is a protocol/extension interaction issue described as enabling downgrade or bypass of integrity checks in certain SSH contexts, frequently discussed under the “Terrapin” name. (NVD) It’s not the same category as “RCE in sshd,” but it’s a reminder: even when SSH remains encrypted, negotiation and extensions can still create security gaps.

CVE-2023-38408, ssh-agent forwarding and PKCS#11 path risk

NVD describes CVE-2023-38408 as an issue in ssh-agent PKCS#11 behavior that can lead to remote code execution if an agent is forwarded to an attacker-controlled system. (NVD) If your org still uses agent forwarding widely, CVE-2024-6387 is a great moment to make “no agent forwarding by default” a policy rather than a suggestion.

When incidents like CVE-2024-6387 hit, the hardest part is rarely “knowing there’s a fix.” The hard part is closing the gap between policy and reality: which assets are exposed, which ones are truly vulnerable given backports, and whether the fix actually landed everywhere you think it did.

Penligent can help you operationalize that gap closure by turning “CVE response” into a repeatable workflow: discover Internet-facing SSH assets, correlate them to package versions and distro advisories, and produce evidence artifacts that prove remediation and hardening changes were applied. That maps cleanly to what teams actually need in the first 24–72 hours: scope, prioritize, patch, verify, and document.

It also fits the longer tail: once the emergency patch is done, you can continuously validate SSH posture—password auth disabled, root login blocked, forwarding constrained, and exposure reduced—so the next regression doesn’t turn into a fleet-wide scramble.

Appendix, a safer way to automate remediation at scale

Ansible example, verify then remediate

This playbook avoids exploit behavior and focuses on verification and configuration changes.

---
- name: CVE-2024-6387 response, verify and harden sshd
  hosts: linux_servers
  become: true
  tasks:
    - name: Gather installed OpenSSH server package version
      shell: |
        (dpkg -l | awk '$2=="openssh-server"{print $3}') 2>/dev/null || true
        (rpm -q --qf '%{VERSION}-%{RELEASE}\\n' openssh-server) 2>/dev/null || true
      register: openssh_pkg
      changed_when: false

    - name: Show openssh-server package version
      debug:
        var: openssh_pkg.stdout_lines

    - name: Ensure sshd_config emergency mitigations are present when patch is delayed
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^LoginGraceTime\\s+'
        line: 'LoginGraceTime 0'
      notify: restart sshd

    - name: Disable password authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication\\s+'
        line: 'PasswordAuthentication no'
      notify: restart sshd

    - name: Validate sshd configuration
      command: sshd -t
      changed_when: false

  handlers:
    - name: restart sshd
      service:
        name: sshd
        state: restarted
      ignore_errors: true

In production, you should gate this with “only apply mitigations if the host is confirmed unpatched,” using distro-specific CVE metadata rather than naive version string comparisons.

Referencias

• NVD entry for CVE-2024-6387 (NVD)
• OpenSSH 9.8 release advisory text, includes affected versions and lab exploitability notes (OpenSSH)
• Ubuntu coordinated release write-up and fix guidance (Ubuntu)
• Qualys regreSSHion overview and affected version framing (Qualys)
• oss-security discussion on CVE-2024-6409 and mitigation caveats (Openwall)
• NVD entry for CVE-2024-6409 (NVD)
• NVD entry for CVE-2023-48795 Terrapin (NVD)
• NVD entry for CVE-2023-38408 (NVD)
• Penligent post on CVE-2024-6387 regreSSHion and response actions (Penligente)
• Penligent XZ Utils CVE guide, a practical “facts-first” remediation style that pairs well with SSH posture work (Penligente)
• Penligent essay on execution boundaries in offensive security, includes SSH as an architectural hinge (Penligente)
• Penligent MITRE ATT&CK practical guide, includes a CVE-2024-6387 case discussion (Penligente)