Active exploitation of OpenSSH CVE-2024-6387 surges midweek as botnets target unpatched Linux and appliance fleets

Security teams on Wednesday reported a renewed spike in attempts to exploit CVE-2024-6387, the OpenSSH server vulnerability known as regreSSHion, across exposed Linux hosts and embedded appliances. The flaw allows unauthenticated remote code execution as root under specific timing conditions, and remains present on internet-facing systems that have not applied vendor fixes issued in 2024.

The uptick matters because more stable exploit code has been folded into commodity attack tooling, lowering the bar for opportunistic operators to gain initial access. Honeypot data shared by multiple researchers shows coordinated mass testing from botnet infrastructure, with attackers parallelizing connections to shorten time to a successful race.

CVE-2024-6387 is a signal handler race condition in sshd before user authentication on glibc based systems, introduced in OpenSSH portable 8.5p1 and fixed in 9.8p1. Exploitation relies on triggering a timeout during the login grace period to hit a window that can corrupt process state. Reliability varies by kernel, CPU, and build flags, but at internet scale attackers can achieve wins by spraying attempts across large address spaces.

A related issue, CVE-2024-6409, affected certain vendor builds where the privsep monitor had a similar race, and was also addressed by distribution updates in 2024. Systems running OpenBSD or non glibc stacks are not impacted by CVE-2024-6387, but many commercial and open source appliances embed portable OpenSSH on Linux and require explicit firmware updates.

Exploitation tradecraft

Intrusion sets observed using regreSSHion typically drop lightweight reverse shells, add attacker keys to authorized_keys for root or privileged users, and establish persistence via cron or systemd. Post exploitation activity often includes rapid credential harvesting, deployment of tunneling tools, and staging of additional payloads from throwaway object storage or paste sites. Defenders should watch for bursts of short lived SSH connections from single sources, high volumes of preauth disconnects, and unexpected changes under /root, /etc/ssh, or user .ssh directories.

Mitigation and detection

Patch OpenSSH to 9.8p1 or the latest vendor backport, then restart sshd. For appliances, apply the latest firmware from the manufacturer, since distro packages do not cover embedded builds. If patching must be deferred, set LoginGraceTime to 0 to remove the vulnerable timer, restrict SSH by IP allowlists or behind a VPN, disable password authentication in favor of keys, and tighten MaxStartups to throttle unauthenticated handshakes. Hunt for persistence, new privileged users, modified authorized_keys, unexpected setuid binaries, and file immutability flags set via chattr.

For enterprise programs, the resurgence underscores two priorities, keep internet edge services on supported versions with fast patch SLAs, and reduce default SSH exposure with network policy, bastions, and strong authentication. Vendors that ship embedded OpenSSH need more consistent firmware maintenance and transparent security advisories, since appliance lag remains a durable entry point for both state aligned and criminal operators.