Qualys this week reported the discovery of a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH servers (sshd) that could potentially impact more than 14 million Linux systems.

The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd) based on a glibc library, allows unauthenticated remote code execution (RCE) as root on Linux systems. This race condition affects sshd in its default configuration and has already been assigned a common vulnerabilities exposure identifier (CVE-2024-6387).

The vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006. A regression in this context means that a flaw, once fixed, has reappeared in a subsequent software release, typically due to changes or updates that inadvertently reintroduce the issue.

Anonymized data collected and analyzed by Qualys suggests that approximately 700,000 external internet-facing instances of Linux are vulnerable. This accounts for 31% of all internet-facing instances with OpenSSH in the Qualys customer base.

Qualys has developed a working exploit for the regreSSHion vulnerability to aid in the remediation process, but the company does not release our exploits. However, despite the complex nature of the exploit, it can be replicated by third parties, the company noted.

Mitch Ashley, principal analyst for TechStrong Research, said the OpenSSH race condition vulnerability is another example of widely used open-source software that now needs to be remediated as quickly as possible.

The challenge is that even when fixed the vulnerability might reappear in subsequent code releases unless there is additional regression testing, he noted. Users of OpenSSH must be diligent about staying on top of new releases, verifying the fixes are still in place before patching, and using enhanced access controls and network segmentation to limit SSH access and any potential blast radius, said Ashley.

As is always the case with software, it’s not enough to identify the issue. Cybersecurity needs to work closely with developers, DevOps engineers and IT operations teams to not only remediate vulnerabilities but ensure that what has been fixed once stays that way. Unfortunately, it’s not uncommon for organizations to find themselves remediating the same vulnerability multiple times across multiple applications built by different development teams.

Theoretically, at least, the adoption of best DevSecOps practices should streamline workflows in a way that reduces that level of friction. The issue is that adoption of best DevSecOps practices within many organizations remains uneven at best.

In the meantime, cybersecurity teams can rest assured that cybercriminals are already researching how to exploit this latest vulnerability. Hopefully, the Linux community will come together once again to fix this issue. However, in the meantime, it’s going to be incumbent upon cybersecurity teams to discover every vulnerable instance of an OpenSSH server that might be running somewhere in their IT environment.

Based on past experiences, in the absence of a software bill of materials (SBOM) it may take some organizations months to determine in an era where many developers never actually bothered to document what software components were deployed and when.