OpenSSH regreSSHion exploit attempts spike against Linux servers, security teams urged to patch CVE-2024-6387
Marcus Webb ·
Security teams returned Monday to elevated exploit traffic against OpenSSH servers vulnerable to CVE-2024-6387, the regreSSHion bug disclosed in July 2024. Opportunistic attackers are probing internet-facing port 22 at scale, seeking unauthenticated remote code execution on Linux systems where sshd is not fully patched. The push is global, driven by widely circulated exploit code and slow patch cycles on appliances and legacy hosts.
The risk matters because exploitation requires no credentials and targets a core remote access service. Several malware operators and botnet crews have integrated the flaw into automated scanners, which means exposed servers can be hit minutes after coming online.
What is being exploited
CVE-2024-6387 is a race condition in the sshd signal handler that can be triggered during the authentication grace period, potentially granting code execution as root on glibc-based Linux. The OpenSSH project released fixes in 9.8p1, and major Linux distributions shipped backported patches through security updates. Systems that have not applied those updates remain exposed.
Appliance and embedded Linux platforms are a weak spot. Network gear, NAS devices, industrial gateways, and older cloud images often run vendor-customized OpenSSH builds, and operators may assume the distro auto-update covers them. In many cases it does not, or updates are disabled for stability.
Immediate actions for defenders
Identify external sshd endpoints and confirm package versions through your configuration management or by querying hosts. Apply vendor security updates that include the OpenSSH 9.8p1 fix or an equivalent backport. If patching must be deferred, implement temporary mitigations by restricting SSH to trusted IPs, placing SSH behind a VPN, or moving SSH to bastion hosts that enforce multifactor authentication.
If a compensating control is needed on a vulnerable host, reduce exposure by setting a minimal or zero LoginGraceTime only as a short term measure, and validate impact on legitimate workflows. Monitor for signs of exploitation such as sshd crashes, core files, unexpected child processes from sshd, new or modified authorized_keys entries, or unknown privileged accounts. Rotate credentials and SSH keys on any system that shows anomalies.
For cloud estates, rebuild from updated images and recreate ephemeral instances to ensure base layers include the patched OpenSSH. The renewed attention on a foundational service underscores the ongoing shift in attacker focus to simple internet reachability and patch gaps over bespoke zero days.