CVE-2024-6387

What it actually does

The vulnerability is a race condition in OpenSSH sshd caused by unsafe signal handling when an unauthenticated connection exceeds the LoginGraceTime authentication window. By repeatedly opening SSH connections and carefully timing authentication failures or stalls, a remote attacker may corrupt sshd process state and, on susceptible builds, achieve unauthenticated remote code execution with the privileges of the sshd process, commonly root. Exploitation is high-complexity and timing-dependent, but public exploit research exists and the EPSS score is extremely high, indicating substantial likelihood of exploitation attempts. The provided product metadata also lists podlove/podlove-publisher GIT as affected with a fix at commit 4d9565d920b0bf08d1beb35bd4908f33e6ca1f18; organizations should validate whether that package metadata is relevant to their asset inventory, because the vulnerability description itself concerns OpenSSH sshd.

Why it matters to the business

Successful exploitation can give an external attacker control of systems that expose vulnerable SSH services, potentially leading to server takeover, data theft, credential theft, lateral movement, service disruption, and deployment of persistence or malware. SSH is commonly exposed for administration, so internet-facing servers are the highest-risk assets. Although this is not currently listed in CISA KEV and is not marked as ransomware-associated, the availability of exploit code, the very high EPSS score, and the long time since publication make unpatched exposure a priority operational risk.

How an attack unfolds

An attacker first identifies hosts exposing SSH and fingerprints the OpenSSH version or distribution package level. They then open many unauthenticated SSH sessions and intentionally do not complete authentication, attempting to trigger sshd's grace-timeout signal path. Because the bug is a race condition, the attacker must repeat the process many times and tune timing, connection volume, and payload behavior for the target operating system, CPU architecture, libc, and sshd build. If the race is won, memory corruption occurs in the privileged sshd process and may be shaped into code execution. A successful attacker can then run commands, add keys or users, deploy a backdoor, collect credentials, and pivot further into the network. Failed exploitation often appears as large volumes of pre-authentication SSH timeouts, connection resets, failed handshakes, or sshd crashes.

How to fix it

Upgrade OpenSSH to a fixed vendor package immediately. For upstream OpenSSH, ensure systems are running a fixed release such as OpenSSH 9.8p1 or a distribution-maintained package that backports the fix. Because Linux distributions often retain older version strings while applying security patches, verify the vendor changelog/security advisory rather than relying only on the OpenSSH banner. Restart sshd after patching and confirm existing listener processes are running the patched binary. Where immediate patching is not possible, reduce exposure by restricting SSH to VPN or trusted management networks, enforcing firewall allowlists, disabling direct internet access to SSH, lowering LoginGraceTime, reducing MaxStartups, and using intrusion-prevention rate limits; these are mitigations, not substitutes for patching. The supplied fixed-version metadata for podlove/podlove-publisher GIT indicates fix commit 4d9565d920b0bf08d1beb35bd4908f33e6ca1f18; if that package is in scope, update to that commit or a later trusted release and remove vulnerable revisions from deployments.

How to confirm the fix worked

Confirm the installed OpenSSH package is fixed using the operating system package manager and vendor advisory data, not only the SSH banner. On Linux, check package changelogs for the relevant regression fix and verify sshd was restarted after update. Validate exposure by enumerating externally reachable SSH services and comparing their package levels to fixed vendor versions. Confirm mitigations by testing that SSH is reachable only from approved networks and that excessive unauthenticated connections are rate-limited. For the supplied GIT package metadata, verify deployed podlove/podlove-publisher code is at commit 4d9565d920b0bf08d1beb35bd4908f33e6ca1f18 or later if that component is relevant. A safe validation approach is configuration and version verification; do not attempt live exploitation against production systems.

Typical attack path

1. Scan for TCP/22 or alternate SSH ports exposed to the internet or reachable from attacker-controlled infrastructure.
2. Fingerprint the SSH banner, OpenSSH version, and operating system/distribution package to determine whether the service is likely vulnerable.
3. Open repeated unauthenticated SSH connections and intentionally delay or fail authentication until the LoginGraceTime timeout path is reached.
4. Tune timing and connection concurrency to increase the chance of winning the race condition in sshd's signal handler.
5. Trigger memory corruption in the privileged sshd process and attempt remote code execution.
6. Establish persistence, such as adding an SSH authorized key, creating a user, modifying startup scripts, or deploying a remote access tool.
7. Collect credentials, inspect sensitive files, move laterally, or use the host as a staging point for further attacks.

How to detect it

Look for evidence of repeated unauthenticated SSH connection attempts, grace-timeout events, abnormal sshd crashes, and post-exploitation behavior. Useful log sources include /var/log/auth.log, /var/log/secure, /var/log/messages, systemd journal entries for sshd, EDR process telemetry, firewall logs, NetFlow, IDS/IPS alerts, and core dump or kernel crash logs. High-signal patterns include bursts of connections from the same source or many distributed sources that never complete authentication, repeated preauth disconnects, LoginGraceTime or timeout messages, sshd segmentation faults, and sudden child processes spawned by sshd such as sh, bash, curl, wget, python, perl, nc, or package managers. Also inspect filesystem changes commonly used for SSH persistence, including new entries in authorized_keys, new local users, modified sshd_config, suspicious files in /tmp or /var/tmp, and new systemd services or cron jobs. Absence of logs does not prove absence of exploitation because failed race attempts may resemble ordinary failed SSH noise and successful exploitation may be followed by log tampering.

• Timeout before authentication for
• Login grace time exceeded
• Connection closed by authenticating user
• Connection closed by invalid user
• Connection reset by authenticating user
• Connection reset by invalid user
• maximum authentication attempts exceeded
• Exceeded MaxStartups
• sshd: fatal: Timeout before authentication
• sshd.*segfault
• segfault at .* in sshd
• audit: ANOM_ABEND.*sshd
• /var/log/auth.log
• /var/log/secure
• /var/log/messages
• /run/systemd/coredump
• /var/lib/systemd/coredump
• /root/.ssh/authorized_keys
• /home/*/.ssh/authorized_keys
• /etc/ssh/sshd_config
• /etc/systemd/system/*.service
• /etc/cron.d/
• /var/spool/cron/
• sshd -> /bin/sh
• sshd -> /bin/bash
• sshd -> curl
• sshd -> wget
• sshd -> python
• sshd -> perl
• sshd -> nc

What your security team should do

• Prioritize patching all internet-facing or broadly reachable SSH servers, especially Linux systems running vulnerable OpenSSH builds.
• Create an emergency inventory of exposed SSH services on TCP/22 and nonstandard ports, including cloud, appliance, container, and edge-hosted systems.
• Verify fixes through vendor package advisories and changelogs, then restart sshd and confirm old vulnerable processes are no longer running.
• Temporarily restrict SSH access to VPN, bastion hosts, or trusted source IP ranges until patching is complete.
• Enable or tune rate limiting for repeated unauthenticated SSH connections using firewall controls, fail2ban-like tooling, MaxStartups, and monitoring rules.
• Review authentication logs, system logs, crash logs, and network telemetry for high-volume pre-authentication timeouts or sshd crashes since publication.
• Hunt for post-compromise activity from sshd process ancestry, including unexpected shells, curl, wget, package managers, new users, modified authorized_keys files, or persistence changes.
• If podlove/podlove-publisher GIT is present in the software inventory, update it to commit 4d9565d920b0bf08d1beb35bd4908f33e6ca1f18 or later and confirm provenance of the dependency metadata.