Weekend surge targets OpenSSH ‘regreSSHion’ CVE-2024-6387, unpatched Linux servers probed ahead of Monday start

Threat actors ramped up exploitation attempts against the OpenSSH regreSSHion bug, tracked as CVE-2024-6387, over the weekend, targeting internet facing Linux servers according to multiple honeypot networks and provider logs. Activity continued into early Monday, raising the risk for organizations that delayed patching or run vendor builds that have not been updated.

Exploit code has been public since July 2024 and attack reliability has improved, which lowers the barrier for botnets and cryptojacking crews that favor weekend intrusion windows. CISA added CVE-2024-6387 to its Known Exploited Vulnerabilities catalog in 2024, a prioritization signal that enterprises should still heed.

What is affected

CVE-2024-6387 is a pre authentication signal handler race condition in sshd on glibc based Linux, a regression of a flaw first fixed in 2006. OpenSSH server versions 8.5p1 through 9.7p1 are vulnerable on Linux with glibc. The issue was fixed in OpenSSH 9.8p1, and major distributions have shipped backports for supported releases.

OpenBSD is not affected, and Linux systems using musl are not affected. Appliances and containers that embed vulnerable OpenSSH builds remain exposed until OEM firmware or base images are refreshed.

Attackers have been observed triggering the vulnerability with bursts of unauthenticated connections to force the race, which can lead to code execution in some cases and to daemon crashes in others. Payloads seen in the wild include shell script droppers that fetch miners, lightweight backdoors, and new SSH keys added to authorized_keys for persistence.

Immediate actions for defenders

• Patch to OpenSSH 9.8p1 or apply vendor backports for supported RHEL, Ubuntu LTS, Debian, and SUSE releases. Verify sshd version and linked libc on internet facing hosts and appliances.
• As a temporary mitigation, set LoginGraceTime to 0 in sshd_config, then restart sshd. This removes the vulnerable code path, but monitor for potential impact on slow client connections.
• Restrict SSH exposure with firewall rules or security groups to known management networks. Enforce key based auth, disable remote root login, and enable rate limiting.
• Hunt for indicators, including repeated pre authentication connection spikes, unexpected sshd crashes or restarts, new users or sudoers entries, changes to authorized_keys, and outbound connections from sshd to unfamiliar hosts.
• Rotate exposed SSH keys and credentials, and review cloud control plane logs for misuse of harvested keys.

The renewed focus on a two year old bug highlights how reliable public exploits and weekend change windows continue to favor opportunistic attackers. Teams that maintain continuous external exposure inventories and KEV aligned patch SLAs will reduce the blast radius when old vulnerabilities resurface in new campaigns.