Download Now

OpenSSH server is currently exposed to a dangerous vulnerability that, if exploited, could grant cybercriminals full system access without user interaction. This post provides an overview of CVE-2024-6387 and suggests remediation responses to mitigate its impact.

What is CVE-2024-6387?

CVE-2024-6387 is a vulnerability in OpenSSH servers (sshd) in 32-bit Linux/glibc systems. If exploited, the vulnerability facilitates Remote Code Execution with full root privileges, classifying it as a high-severity exposure (CVSS 8.1).


CVE-2024-6387 (discovered on 1 July 2024) isn't an entirely new exposure. It's a regression from a previously patched vulnerability CVE-2006-5051, first discovered in 2006 (hence the codename regreSSHion).

At the heart of this issue is a signal-handler race condition vulnerability within the sshd process of OpenSSH servers, which facilitates code execution on impacted systems with the highest level of system privileges, root privileges.

A race condition is triggered when system operations occur out of order, disrupting a system's ideal end state.

In this instance, the race condition is triggered because the sshd process on glibc-based Linux systems uses syslog() to asynchronously call functions like malloc() and free(), which are used to manage memory allocation. 

"Malloc() is not safe to call asynchronously (eg. from signal handlers). Doing so results in a race-condition vulnerability making the malloc operation susceptible to interruption using SIGALRM, leaving the heap in an inconsistent exploitable state 

Root privilege access is possible because sshd's privileged code, by design, runs with full privileges by default instead of being sandboxed. This design decision increases the OpenSSH server process's vulnerability to cyberattacks.

Exploitation of CVE-2024-6387 requires a cyber attack design of reasonable complexity, requiring hackers to force a high volume of race conditions for an unknown period of time to achieve RCE, which explains the current lack of PoC code for this vulnerability in the wild. That being said, exploitation is still a possibility, and all impacted SSH servers must be updated immediately.

Which OpenSSH versions are impacted?

OpenBSD-based servers are not impacted by the OpenSSH regreSSHion vulnerability.

Responding to CVE-2024-6387

The immediate course of action is to update impacted SSH servers to the latest version, 9.8p1 (see OpenSSH release notes).

To circumvent any version update delays, admins can force an immediate update by temporarily setting the login timeout to zero (LoginGraceTime=0 in sshd_config). Just keep in mind that this configuration could make SSH servers more vulnerable to DDoS attacks, so it should only be used as a temporary workaround if the risk is deemed acceptable. 

Additional risk mitigation steps include:

  • Segregating internal networks to disrupt unauthorized access attempts to sensitive regions.
  • Implement triggers and monitoring solutions for suspicious internal activities.
  • Configuring your firewall to limit SSH access to certain IP addresses.

How to detect CVE-2024-6387

With UpGuard BreachSight, you can identify whether your internal IT infrastructure is impacted by searching for CVE-2024-6387 in the detected vulnerabilities feed.

CVE-2024-6387 detection within the vulnerabilities module in UpGuard BreachSight.‍
CVE-2024-6387 detection within the vulnerabilities module in UpGuard BreachSight.

To determine which of your third-party vendors are impacted by CVE-2024-638, search for it in the Portfolio Risk Profile within UpGuard Vendor Risk.

Third-party vendors impacted by CVE-2024-21410 are automatically flagged in UpGuard Vendor Risk
Third-party vendors impacted by CVE-2024-21410 are automatically flagged in UpGuard Vendor Risk

Each detected instance of exposure to the OpenSSH regreSSHion can then instantly be progressed through remediation and risk management workflows natively integrated into UpGuard to form an all-in-one Vendor Risk Management solution

Ready to see
UpGuard in action?

Ready to save time and streamline your trust management process?