OpenSSH CVE-2024-6387 (RegreSSHion) vulnerability could cause RCE to be subjected to mass exploitation? 

OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies
OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies, RegreSSHion

A new Vulnerability affecting OpenSSH, regression, with CVE identifier CVE-2024-6387 (named RegreSSHion), has been discovered, and wide exploitation is possible; in the article, we’ll explore the impact, the likelihood of this to happen and how to tackle external system upgrades with ASPM technologies quickly. This vulnerability affects OpenSSH, a widely used suite of secure networking utilities based on the Secure Shell (SSH) protocol. In this article, we delve into the details of CVE-2024-6387, its impact, the complexities involved in its exploitation, and how organizations can mitigate the associated risks.

The challenge of this vulnerability is that it could potentially impact tens of thousands of software being very popular ssh components and embedded in glibc.

Could OpenSSH CVE-2024-6387 (RegreSSHion) vulnerability cause RCE to be subjected to mass exploitation? 

“The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems,” Bharat Jogi, senior director of the threat research unit at Qualys

Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with [address space layout randomization],” OpenSSH said in an advisory. “Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept.”

Key points about CVE-2024-6387:

  • Vulnerability: Remote Unauthenticated Code Execution (CVE-2024-6387)
  • Affected: OpenSSH 8.5p1 to 9.8p1
  • Architecture: Primary PoC for 32-bit (x86), 64-bit (amd64) theoretically vulnerable
  • Systems: glibc-based Linux distributions
  • Impact: Root-level access if exploited
  • Complexity: High (requires precise timing, multiple attempts)
  • Status: Patch available (OpenSSH 9.8p1)

Note:

Qualys describes the vulnerability as highly complex to exploit, requiring an average of around 10,000 exploitation attempts to succeed.

under ideal conditions, you can perform about 5 attempts per minute, so 10,000 attempts would take around 1.4 days. This is also in a lab environment where network lag is negligible, as is SSH background noise. On a real internet-connected system experiencing network jitter and being blasted by SSH scanners, exploitation could take significantly longer. From a link in Mark Hutchins 

What Does OpenSSH Stand For?

OpenSSH stands for Open Secure Shell. It is an open-source implementation of the SSH protocol, which provides encrypted communication sessions over unsecured networks. OpenSSH includes a set of secure networking utilities designed to offer robust encryption, secure file transfers, and secure remote logins, making it an essential tool for administrators and developers managing servers and networked systems.

What is OpenSSH Vulnerability?

An OpenSSH vulnerability refers to a security flaw found within the OpenSSH software that can be exploited by attackers to compromise system security. The regreSSHion vulnerability (CVE-2024-6387) is a prime example. It is a signal handler race condition in the OpenSSH server component (sshd), allowing unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems. This makes it a critical threat, as it could potentially allow attackers to gain full control over affected systems.

What is the Difference Between SSH and OpenSSH in RegreSSHion?

SSH, or Secure Shell, is a protocol used to secure remote logins and other network services over an unsecured network. OpenSSH is an open-source implementation of the SSH protocol, providing a suite of tools that include SSH clients and servers, as well as utilities for secure file transfers and other secure network operations. While SSH is the protocol itself, OpenSSH is a widely used implementation of that protocol.

Where is OpenSSH Used?

OpenSSH is used in a variety of environments to ensure secure communication and data transfer. It is commonly deployed for remote server management, secure file transfers, automated backups, and batch processing. OpenSSH’s robust security features and flexibility make it a cornerstone in DevOps practices, where secure handling of sensitive data across multiple systems and locations is crucial.

What is Regression? Why CVE-2024-6387 has been named RegreSSHion?

In software development, regression refers to the reappearance of a previously fixed bug or vulnerability in a subsequent software release. This can occur due to changes or updates that inadvertently reintroduce the issue. The regreSSHion vulnerability is a regression of the previously patched CVE-2006-5051, highlighting the importance of thorough regression testing to prevent known vulnerabilities from re-entering the environment. ASPM technologies helps identify new and older version by cataloguing the version of the library

What Systems Are Affected?

The regreSSHion vulnerability affects glibc-based Linux systems running vulnerable versions of OpenSSH. Specifically, it impacts versions from 8.5p1 to 9.7p1. Versions earlier than 4.4p1 are also vulnerable unless they have been patched for both CVE-2006-5051 and CVE-2008-4109. Notably, OpenBSD systems are unaffected due to a security mechanism implemented in 2001. ASPM technologies helps scaling remediation efforts

Are There Exploits for CVE-2024-6387?

OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies, Exploit, Exploitation, PoC

When it comes to cybersecurity, understanding the exploitation potential of a vulnerability is crucial. The regreSSHion vulnerability, identified as CVE-2024-6387, is no exception. This section delves into the existence and complexity of exploits for this vulnerability, shedding light on the practical challenge potential attackers face.

Proof-of-Concept (PoC) for CVE-2024-6387

As of the latest update, a Proof-of-Concept (PoC) for CVE-2024-6387 exists. This PoC targets certain i386 (32-bit) versions of OpenSSH where the GNU C Library (glibc) is at a static base address. This scenario bypasses Address Space Layout Randomization (ASLR), a security feature that randomizes memory addresses to make exploitation more difficult. In systems where ASLR is not bypassed, the complexity and time required to exploit the vulnerability increase significantly. ASPM technologies and Phoenix cyber intelligence helps identify when a vulnerability is weaponized or is in a PoC state

How to remediate CVE-2024-6387?

OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies, PoC, Exploit, Evidence, RegreSSHion

With Phoenix security, you can search for active campaign

How to identify CVE-2024-6387?

We amended some of the script to identify the vulnerable version and to output the vulnerabilities that can be imported into Phoenix Security

https://github.com/Security-Phoenix-demo/CVE-2024-6387_Check_phoenix_Security

Github, phoenix security script, OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies, PoC, Exploit, Evidence, RegreSSHion

Scanning for CVE-20246387 can be simple, and there are at least a couple of scripts that enable the identification of the vulnerability

You can import the vulnerable file:

import, phoenxi security, OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM

Other options are

Exploitation Complexity CVE-2024-6387

Qualys’ whitepaper highlights the high complexity involved in exploiting CVE-2024-6387. Under lab conditions, it took an average of around 10,000 exploitation attempts to succeed. Several factors contribute to this complexity:

  • Login Timeout: The exploitation process is restricted by the login timeout setting, which ranges between 120 to 600 seconds.
  • Concurrent Connections: OpenSSH typically allows a maximum of 10 concurrent unauthenticated connections.
  • Exploitation Rate: Under ideal conditions, this setup permits about five attempts per minute. Thus, achieving 10,000 attempts would take approximately 1.4 days.

These conditions are based on an ideal lab environment with negligible network lag and minimal SSH background noise. In real-world scenarios, factors such as network jitter and interference from SSH scanners could extend the exploitation timeframe significantly.

How many systems are exposed to CVE-2024-6387

Qualys’ whitepaper highlights the high complexity involved in exploiting CVE-2024-6387. Under lab conditions, it took an average of around 10,000 exploitation attempts to succeed. Several factors contribute to this complexity.

Currently, there are around 61,800 openssh exposed systems according to shodan

Shodan, CVE-2024-6387, Exploit

Shadowserver has observed a higher number of them, with the count reaching ~4.5M hosts possibly vulnerable 2024-07-02 (out of over 23.5M seen), while the number is high there is no active exploitation at the moment and the exploitability requirement are still high

Shadowserver, OpenSSH, Exposure

Advanced Exploitation TechniquesCVE-2024-6387

While the PoC provides a starting point, successful exploitation of CVE-2024-6387 in a real-world environment is challenging. Attackers would need to:

  • Overcome ASLR: On modern systems (x86_64 / AMD64), ASLR significantly complicates the exploitation process. Predicting memory addresses becomes a game of chance, reducing the probability of success with each attempt.
  • Handle Network Latency: Real-world networks introduce latency and jitter, making precise timing of exploitation attempts more difficult.
  • Mitigate Background Noise: The presence of legitimate and illegitimate SSH traffic can obscure exploitation attempts, requiring additional measures to isolate and execute the attack.

Realistic Threat Assessment

Given these complexities, it is unlikely that CVE-2024-6387 will see widespread in-the-wild exploitation similar to other high-severity vulnerabilities. However, the possibility remains that sophisticated attackers could develop more efficient methods over time. Organizations must remain vigilant and prioritize patching and other mitigations to protect against potential exploitation.

Update (2024-07-01 11:09 PST)

The recent update notes that while there is a PoC for i386 systems, the estimated exploitation time is based on these older systems. For newer systems running x86_64 / AMD64, exploitation would take significantly longer due to the necessity of overcoming ASLR. This further reduces the likelihood of mass exploitation but does not eliminate the risk entirely.

Mitigation Strategies

RegreSSHion

To mitigate the risks associated with CVE-2024-6387, organizations should:

  1. Apply Patches Promptly: Ensure that all systems running vulnerable versions of OpenSSH are updated to the latest secure versions.
  2. Limit SSH Access: Use network-based controls to restrict SSH access to trusted IP addresses and employ VPNs where possible.
  3. Implement Network Segmentation: Separate critical systems from less secure parts of the network to limit the potential impact of a successful exploit.
  4. Monitor and Alert: Deploy and configure intrusion detection and prevention systems to detect and alert on exploitation attempts.

How Could I Discover If I’m Affected by CVE-2024-6387?

To determine if you are affected by CVE-2024-6387, you should check the version of OpenSSH running on your systems. If your version falls within the vulnerable range (8.5p1 to 9.7p1, or earlier than 4.4p1 without patches), you are at risk. Vulnerability scanning solutions like Qualys or Phoenix security external scanners can help you stay updated.

What Version of OpenSSH is Vulnerable to CVE-2024-6387?

The versions of OpenSSH vulnerable to CVE-2024-6387 are from 8.5p1 up to, but not including, 9.8p1. Versions earlier than 4.4p1 are also vulnerable unless patched for CVE-2006-5051 and CVE-2008-4109. Ensuring your OpenSSH installation is updated beyond these versions is critical to mitigate the risk.

The Complexity of Exploiting CVE-2024-6387

According to Qualys’ whitepaper, exploiting CVE-2024-6387 is highly complex. It requires an average of around 10,000 exploitation attempts to succeed under lab conditions. The number of attempts is restricted by the login timeout setting (120-600 seconds) and the maximum concurrent unauthenticated connections (10). Under ideal conditions, you can perform about five attempts per minute, so 10,000 attempts would take around 1.4 days. This estimate assumes a lab environment with negligible network lag and minimal SSH background noise. In real-world scenarios, with network jitter and interference from SSH scanners, exploitation could take significantly longer.

Update (2024-07-01 11:09 PST)

There does appear to be a proof-of-concept (PoC) for certain i386 (32-bit) versions of OpenSSH where glibc is at a static base address, eliminating the need for an ASLR bypass. Since the estimated exploitation time is based on i386, it can be assumed that newer systems (those running x86_64 / AMD64) would take significantly longer to exploit due to the need for an ASLR bypass. While it’s entirely possible that attackers find ways to optimize the exploit further, given the complexity and time commitment, it’s unlikely we would see the same kind of massive in-the-wild exploitation observed with other vulnerabilities of similar severity.

The Impact of regreSSHion

The impact of the regreSSHion vulnerability is far-reaching, given the widespread use of OpenSSH. A successful exploit could lead to a full system compromise, allowing attackers to execute arbitrary code with root privileges. This could result in a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access. Moreover, an exploited system could be used as a foothold to traverse and exploit other vulnerable systems within an organization, facilitating network propagation.

Qualys’ findings indicate that there are no less than 14 million potentially vulnerable OpenSSH server instances exposed to the internet, with around 700,000 of these being external internet-facing instances. This highlights the significant risk posed by the regreSSHion vulnerability and underscores the importance of timely patching and robust security practices.

OpenSSH, Vulnerability, Cybersecurity, CVE-2024-6387, ASPM, ASPM Technologies, PoC, Exploit, Evidence, RegreSSHion

Mitigating the Risks of regreSSHion

To mitigate the risks associated with CVE-2024-6387, organizations should take several key steps:

  1. Patch Management: Apply the latest patches for OpenSSH immediately. Ensuring that your OpenSSH installation is updated beyond the vulnerable versions is crucial to mitigate the risk of regression vulnerability, even if it is marginal. ASPM technologies with campaigns of remediation can help with scaling
  2. Access Control: Limit SSH access through network-based controls. Restricting SSH access to trusted IP addresses and using VPNs can help reduce the attack surface.
  3. Network Segmentation: Implement network segmentation to restrict unauthorized access and lateral movement. Separating critical systems from less secure parts of the network can limit the impact of a successful exploit.
  4. Monitoring and Alerting: Deploy intrusion detection and prevention systems to monitor for unusual activities indicative of exploitation attempts. Timely alerts can help administrators respond swiftly to potential threats.

How Phoenix Security ASPM Can Help

Phoenix Security offers comprehensive solutions to help organizations focus on the vulnerabilities that matter most by adopting a risk-based prioritization approach. Here’s how Phoenix can assist:

  • Likelihood of Exploitation: Assess the likelihood of exploitation based on various factors, prioritising high-risk vulnerabilities.
  • Actual Chances of Exploitability Using EPSS Scores: Utilize Exploit Prediction Scoring System (EPSS) scores to determine the actual chances of exploitability, enabling better prioritization of remediation efforts.
  • Threat Intelligence: Leverage threat intelligence to stay informed about emerging threats and vulnerabilities like PoC in github (current status of RegreSSHion), evidence of exploitation and weaponization to enhance ASPM technologies
  • Internal/External Exploitation: Consider both internal and external exploitation vectors to provide a holistic view of the risk landscape.
  • Verified Sources of Exploitation: Use verified sources of exploitation, such as CISA KEV and Metasploit, to confirm the presence and severity of vulnerabilities. ASPM Technologies help identify the vulnerabilities faster
  • Business Impact and Consequences of Vulnerability: Evaluate the business impact and consequences of vulnerabilities to ensure that remediation efforts align with organizational priorities.

Phoenix Security ASPM helps organizations move towards a risk-based approach, focusing on the 1% of vulnerabilities that matter most instead of a reactive approach. Organizations can significantly enhance their security posture and mitigate potential threats by prioritising vulnerabilities based on actual risk and impact.

Conclusion

The regreSSHion vulnerability (CVE-2024-6387) in OpenSSH underscores the importance of rigorous security practices and timely patch management. The risks are significant with millions of potentially vulnerable instances exposed to the internet. However, organisations can mitigate these risks and protect their critical assets by understanding the complexity of exploitation, implementing security measures, and leveraging solutions like those offered by Phoenix Security ASPM.

For more detailed information on the regreSSHion vulnerability, you can read the articles on SC Magazine, The Hacker News, and explore the concepts of exploitability and top exploited vulnerabilities on Phoenix Security and Phoenix Security Tag: Top Exploited

How Phoenix Security Can Help

attack graph phoenix security
ASPM

Phoenix Security helps organizations identify and trace which systems have vulnerabilities, understanding the relation between code and cloud. One of the significant challenges in securing applications is knowing where and how frameworks like OpenSSH are used. ASPM tools can scan the application portfolio to identify instances of OpenSSH, mapping out where it is deployed across the organization. This information is crucial for targeted security measures and efficient patch management. Phoenix Security’s robust Application Security Posture Management (ASPM) system is adept at not just managing, but preempting the exploitation of vulnerabilities through its automated identification system. This system prioritises critical vulnerabilities, ensuring that teams can address the most pressing threats first, optimising resource allocation and remediation efforts.

The Role of Application Security Posture Management (ASPM):

ASPM plays a vital role in managing and securing applications like those built with OpenSSH. It involves continuous assessment, monitoring, and improvement of the security posture of applications. ASPM tools can:

  1. Identify and Track OpenSSH Components: Locate where OpenSSH is implemented within the application infrastructure.
  2. Vulnerability Management: Detect known vulnerabilities in OpenSSH and prioritize them for remediation.
  3. Configuration Monitoring: Ensure OpenSSH configurations adhere to best security practices

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.

Get in control of your Application Security posture and Vulnerability management

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Are never-ending critical alerts leaving you scrambling? Explore how reachability analysis identifies vulnerabilities that truly matter, saving your teams from needless patch frenzies. This session, hosted by the OWASP NYC Chapter, uncovers the latest insights in ASPM, remediation techniques, and application security best practices. Attendees learn how to streamline vulnerability management through practical examples, advanced risk scoring, and live demonstrations of container-based architectures. Expect lively discussions, real-world success stories, and expert tips on targeting only the exploitable weaknesses—rather than chasing every single alert in your backlog.
Francesco Cipollone
The cybersecurity landscape is evolving rapidly, demanding a threat-centric, risk-based approach to vulnerability management. With the U.S. favoring voluntary guidelines and Europe enforcing stricter regulations, organizations must navigate compliance while focusing on real exploitability over CVE volume. This blog delves into ASPM, cloud security, and regulatory intelligence, exploring how businesses can move beyond the traditional patch-and-pray model to address root cause vulnerabilities before they become critical risks.
Francesco Cipollone
Enhance your vulnerability management with Application Security Posture Management (ASPM) and reachability analysis. Discover how ASPM helps prioritize exploitable vulnerabilities, reduce security noise, and improve risk management. Learn about advanced techniques like code and container reachability, contextual deduplication, and Phoenix Security’s cutting-edge solutions for smarter, more effective application security.
Francesco Cipollone
The 2024 CWE Top 25 is out, and it’s no casual stroll through the vulnerability garden—especially when ransomware operators are busy planting path traversal exploits, while bug bounty hunters dig up endless injection flaws. In this blog, we examine the biggest risers, the most surprising dips, and the divergence between real-world exploit data and official CWE rankings. We’ll also reveal how AI-driven ASPM (Application Security Posture Management) and Phoenix Security’s contextual risk-based approach unite to help you focus on your most pressing threats. After all, not all flaws are created equal—some are simply more mischievous than others.
Francesco Cipollone
The 2024 CWE Top 25 list highlights the most dangerous software weaknesses. This article explores the methodology behind the list and how AI is improving threat detection. Discover how Application Security Posture Management (ASPM) and unified vulnerability management can help organizations address these critical threats.
Francesco Cipollone
Phoenix Security kicks off 2025 with recognition from Gartner Digital Markets through GetApp, solidifying its position as a leader in Application Security Posture Management (ASPM). Recognised for best customer success and support in ASPM, Phoenix Security empowers organisations with comprehensive, contextual vulnerability management and actionable cybersecurity solutions. With a user-friendly interface, robust real-time monitoring, and seamless risk prioritisation, the platform reduces alert fatigue while delivering precise remediation. As a cloud security leader, Phoenix Security continues to innovate, partnering with enterprises like LastPass and ClearBank to tackle the modern cybersecurity landscape head-on.
Francesco Cipollone
Derek

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

christophe

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

jim

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

The IKIGAI concept
x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
ShieldPRO