CVE-2024-6387: OpenSSH regreSSHion RCE Remediation

A race condition in OpenSSH's sshd signal handler — a regression of CVE-2006-5051 — re-enabled unauthenticated remote code execution as root on affected glibc-based Linux servers. The bug is reached through the LoginGraceTime SIGALRM handler. The OpenSSH 9.8 release notes classify it as critical, and the Qualys regreSSHion advisory documents successful exploitation in lab conditions.

CISA's official Known Exploited Vulnerabilities JSON feed (catalogVersion 2026.08.21, released 2026-08-21) does not list CVE-2024-6387. Secondary articles that claim a 2026-02-25 KEV addition are not authoritative unless they match that live feed. This recipe keeps kev: false until CISA publishes an entry. Rechecked against the OpenSSH 9.8 release notes, the Qualys advisory, NVD, and the CISA KEV JSON on 2026-08-21. Live GHAD GHSA-2x8c-95vh-gfv4 has vulnerabilities empty. NVD OpenSSH CPE last-affects including 9.8 from 8.6, plus exact 4.4 / 8.5 / 8.6. Vendor and Qualys name 9.8p1. 9.8p1 is not an NVD exclude. Do not invent a later 9.9p1 floor.

Affected versions

• OpenSSH versions earlier than 4.4p1 — vulnerable to the original 2006 issue (and to this one if other patches weren't backported).
• OpenSSH 4.4p1 through versions earlier than 8.5p1 — not vulnerable to this signal-handler race (the 2006 fix held).
• OpenSSH 8.5p1 through 9.7p1 — vulnerable (regression reintroduced) in vendor and Qualys prose.
• OpenSSH 9.8p1+ — patched in vendor and Qualys prose.
• Vulnerable / NVD CPE: OpenSSH exact 4.4 / 8.5 / 8.6 and >= 8.6 last-affects including 9.8. There is no GHAD first_patched and no 9.8p1 exclude.
• Do not invent: flatten leftover 9.8p1 onto NVD including 9.8, or invent 9.9p1.

OpenBSD is not vulnerable. Qualys demonstrated unauthenticated root RCE on glibc-based Linux and explicitly did not investigate every other libc or operating system, so a non-glibc platform alone is not proof of safety. Linux distributions also backport fixes under their own package versions; use the vendor or distribution advisory as the authoritative package-status check.

Indicator-of-exposure

Detection:

ssh -V    # Reports the OpenSSH version
sshd -V 2>&1 | head -1   # Sometimes more accurate

# Also verify against the distro advisory
apt-cache policy openssh-server
dnf info openssh-server

Sufficient exposure conditions:

• glibc-based Linux, where unauthenticated root RCE was demonstrated. For other platforms, require a vendor or distribution affectedness statement rather than assuming they are safe.
• OpenSSH version in the 8.5p1–9.7p1 window.
• sshd reachable by an attacker.
• Default LoginGraceTime (120 seconds). The mitigation setting is LoginGraceTime 0, which closes the race window by removing the alarm.

A network-isolated sshd (only reachable from a bastion or internal-only) is a smaller exposure surface but still vulnerable to anyone who reaches the bastion.

Remediation strategy

• Upgrade OpenSSH to 9.8p1+ via the distro's package manager.
• Mitigate with LoginGraceTime 0 in /etc/ssh/sshd_config until the upgrade lands. This removes the alarm-based race entirely; the cost is that a client hanging the auth handshake holds an sshd slot forever (a MaxStartups setting becomes load-bearing).
• Restart sshd after either action.
• Audit authentication logs for unusual volumes or patterns of pre-auth timeouts and failed connections. A Timeout before authentication line is not, by itself, proof of exploitation.
• Escalate for incident-response assessment when affected sshd was reachable from untrusted networks or telemetry is suspicious. Version and reachability prove exposure, not compromise; the incident owner decides whether host-key or secret rotation and host rebuilds are required.

When to use it

Use this recipe when a Linux host, container image, appliance, VM base image, or infrastructure repository may run affected OpenSSH sshd. Remote root RCE was demonstrated on glibc-based Linux; other platforms still require an authoritative vendor or distribution affectedness decision. It is most important for public or bastion-reachable servers, management containers, CI images, golden images, or fleets where sshd exposure and restart ownership are split across teams.

Use it to distinguish package remediation from incident response: upgrade or mitigate, identify the restart owner, classify exposure, and produce host-key rotation and log-review actions when the service was reachable. Do not use it to bundle unrelated SSH hardening or firewall redesign into the same change.

Inputs

• Host inventories, image manifests, SBOMs, package locks, distro advisories, Terraform/Ansible/cloud-init/Packer config, container Dockerfiles, SSHD config, systemd units, and operational runbooks.
• OpenSSH server version evidence from sshd -V, package managers, image scans, distro backport advisories, custom build metadata, and runtime inventory.
• Platform and exposure evidence: operating system, libc, vendor or distro advisory status, listening interfaces, firewall/bastion controls, LoginGraceTime, MaxStartups, public internet reachability, auth logs, and exposure-window timing.
• Operator-owned secrets and trust anchors reachable by sshd: host keys, host certificates, PAM/AuthorizedKeysCommand outputs, deploy credentials, CI credentials, and artifacts produced on the host.
• Change-control constraints for package upgrades, config mitigation, reload or restart timing, session impact, auth-log retention, key rotation, and host rebuilds.

The prompt

You are remediating CVE-2024-6387 (regreSSHion) on this host
or in this system image. Output exactly one of:

- A PR / change request upgrading OpenSSH and (optionally)
  applying the `LoginGraceTime 0` mitigation, plus an IR
  checklist for the operator.
- A TRIAGE.md if the host has been running affected `sshd`
  on the public internet for an extended period.

This recipe is **not** auto-merge. The agent produces the PR;
the operator restarts `sshd` and decides on IR scope.

## Step 0 — Detect

1. Read OpenSSH server version: `sshd -V 2>&1 | head -1`.
2. Record the operating system, libc, and vendor or distro advisory status;
   `ldd --version | head -1` can help identify glibc but does not decide
   affectedness on its own.
3. Read `/etc/ssh/sshd_config` for the current
   `LoginGraceTime` value.
4. Determine network exposure: is `sshd` listening on a
   public interface? Is it firewalled to a bastion?

## Step 1 — Classify

- **Vendor or distro confirms the installed build is fixed or not affected:**
  document the advisory and package evidence, then stop.
- **Affected, not network-reachable from untrusted nets:**
  upgrade + restart, no IR escalation.
- **Affected, network-reachable from the public internet for
  an extended window:** write a triage note for operator-led incident-response
  assessment; do not claim compromise or auto-rotate keys.

## Step 2 — Upgrade

1. `apt upgrade openssh-server` /
   `dnf upgrade openssh-server` to the distro's patched
   version.
2. Verify the new version: `sshd -V`.
3. The PR body lists `systemctl restart sshd` as an
   operator action. The agent does not restart the service.

## Step 3 — Mitigate (interim)

If the upgrade cannot ship immediately, propose a config
change:

```
# In /etc/ssh/sshd_config
LoginGraceTime 0
MaxStartups 10:30:100
```

`LoginGraceTime 0` removes the alarm entirely. Tighten
`MaxStartups` to keep an attacker from holding open many
slots. Recommend a `systemctl reload sshd` after the change.

## Step 4 — IR checklist (compromised classification)

The TRIAGE.md must include:

- Decide whether the exposure and telemetry warrant rotating SSH host keys.
- Audit `auth.log` / `journalctl -u ssh` for
  `Timeout before authentication` lines and unusual login
  patterns during the exposure window.
- If compromise is suspected or confirmed, rotate secrets in scope for the
  affected host, including host certificates and credentials exposed through
  PAM or `AuthorizedKeysCommand` integrations.
- Audit any deploy / CI workflows that authenticated to this
  host during the window.
- Rebuild any artifact produced on the host while it was
  affected and reachable.

## Stop conditions

- The vendor or distribution advisory confirms that the installed platform and
  package build are fixed or not affected.
- The host's distro has no patched OpenSSH packaged yet.
  Apply the `LoginGraceTime 0` mitigation; triage with a
  note about the missing package.
- The host's exposure window is unclear or the auth log
  rotation has lost evidence.

## Scope

- Do not modify SSH client configuration.
- Do not modify firewall rules — mention them in the PR body
  as a reviewer-considered defence-in-depth.
- Do not bundle unrelated CVEs.
- Do not run `systemctl restart sshd`. Restarting `sshd` is
  the operator's call (severs in-flight sessions).

Verification — what the reviewer looks for

• The package version after upgrade matches the distro's patched version.
• If the mitigation was applied: LoginGraceTime 0 is present and MaxStartups is sane.
• The PR body's IR scope matches the host's exposure classification — the reviewer doesn't accept "it was internal" without seeing how that was confirmed.
• For compromised classification, confirm the IR actions were carried out before merge.

Watch for

• Distro version strings. Some distros backport patches without bumping the upstream version string. The authoritative check is the distro advisory, not sshd -V.
• Custom-compiled OpenSSH. Hosts running OpenSSH built from source do not get the distro patch. Treat as a separate remediation; rebuild from a clean tree.
• MaxStartups interactions. Setting LoginGraceTime 0 without raising MaxStartups can become an availability bug — clients failing-to-authenticate hold slots forever. Tune both together.
• Bastion-only exposure isn't no exposure. A bastion that itself is reachable becomes the same target. The IR scope should follow the chain.
• Containerised sshd. Some images run sshd for management. Image bumps follow the base-image workflow; this recipe applies to the package inside the container.

Output contract

Return one of:

• A reviewer-ready PR/change request that upgrades the controlled OpenSSH package or image, optionally applies LoginGraceTime 0 with sane MaxStartups as an interim mitigation, identifies restart/reload actions, verifies the distro-patched status, and attaches an operator IR checklist.
• TRIAGE.md when public or unclear exposure requires incident handling, no patched distro package is available, custom-compiled OpenSSH must be rebuilt outside this repository, or restart/host-key rotation ownership is external.

The output must list OpenSSH version evidence, distro advisory status, glibc status, exposure path, LoginGraceTime and MaxStartups, restart owner, auth-log review commands, host keys or secrets requiring rotation, and validation commands. It must not restart production sshd, modify SSH client config, silently change firewall rules, or bundle unrelated CVEs.

Rollback

Do not roll back into NVD-listed OpenSSH 8.5 / 8.6 through 9.8 or into vendor 8.5p1–9.7p1. Do not flatten leftover 9.8p1 onto the NVD including-9.8 row and do not invent a first_patched from the empty GHAD vulnerabilities list.

References

• OpenSSH 9.8 release notes: https://www.openssh.com/txt/release-9.8
• Qualys regreSSHion security advisory: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-6387
• CVE record: https://www.cve.org/CVERecord?id=CVE-2024-6387
• CISA KEV JSON feed (authoritative KEV source; this CVE is not listed as of 2026-08-21): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

Related recipes

• Vulnerable Dependency Remediation — generic CVE workflow.
• Base Image & Container Layer Remediation — for OpenSSH inside container bases.