Active exploitation of OpenSSH CVE-2024-6387 intensifies mid‑week, mass scanning hits internet‑exposed Linux servers
Marcus Webb ·
Security firms and incident responders on Wednesday reported sustained exploitation attempts against CVE-2024-6387, the OpenSSH regreSSHion bug that enables unauthenticated remote code execution on many Linux servers. Adversaries are using publicly available exploits to obtain root on unpatched hosts, then establishing persistence and staging credentials for follow-on data theft and ransomware.
The volume matters because many enterprises still run long term support distributions that shipped vulnerable OpenSSH builds, and patch deployment lags on internet-facing bastion hosts. Automated scanners are discovering targets at scale, which compresses the window between disclosure and compromise for organizations that have not applied vendor fixes.
Exploitation relies on a signal handler race in sshd that can be triggered pre authentication on glibc-based Linux systems. Reliability varies by architecture, researchers observed higher success on 32-bit builds, but mass scanning compensates through repetition. Once in, operators commonly add attacker-controlled keys to root or service accounts, flip PermitRootLogin to yes, drop SUID shells, and deploy systemd timers or cron jobs to regain access.
Defenders should prioritize upgrading to a fixed OpenSSH release, including vendor backports provided by Red Hat, Ubuntu, Debian, and other distribution maintainers. The upstream patch was incorporated in OpenSSH 9.8p1, and distribution advisories provide corrected package versions for supported releases. Reboots are not usually required, but sshd must be restarted for the fix to take effect.
Where immediate patching is not possible, apply layered mitigations. Restrict SSH to trusted administrative networks with firewall rules or a VPN, enforce multi factor access via bastion hosts, and set conservative MaxStartups to throttle unauthenticated connection bursts. Setting LoginGraceTime to 0 disables the vulnerable code path, but it can create resource exhaustion risk, so use only as a short-term measure with strong connection filtering.
H2: What to monitor Review auth and syslog for dense clusters of failed SSH handshakes and repeated short-lived connections from diverse IPs. Investigate unexpected changes to sshd_config, new entries in authorized_keys for privileged accounts, unfamiliar systemd units, and outbound connections from bastion hosts to unusual destinations. EDR telemetry that flags interactive shells spawned by sshd or modifications to /etc/passwd and /etc/shadow on jump boxes can provide early detection.
H2: Why it affects cloud workloads Compromise of a single SSH gateway frequently exposes cloud credentials cached on administrators’ workstations and on management nodes. Attackers are harvesting keys and tokens to move into cloud control planes, then creating new access paths that persist beyond a simple package update. Securing SSH on premises reduces the blast radius for SaaS and IaaS estates that rely on hybrid administration.
For the broader technology landscape, the campaign reinforces a trend where widely deployed infrastructure components become reliable entry points long after disclosure. Teams that automate telemetry-driven patching for core services like SSH and that enforce network segmentation for administrative access reduce both dwell time and adversary leverage during peak mid-week exploitation waves.