OpenSSH 'RegreSSHion' RCE Vulnerability

A critical vulnerability in OpenSSH's server, dubbed 'regreSSHion,' raises the risk of remote code execution with root privileges.
Jason Hill
4 min read
Last updated July 2, 2024
Varonis Threat Labs

Researchers from the Qualys Threat Research Unit recently published details of their discovery of a critical vulnerability in OpenSSH’s server ‘sshd, ’ dubbed ‘regreSSHion’ and assigned the CVE-2024-6387 identifier.

The vulnerability affects the default configuration of certain sshd versions on glibc-based Linux systems. If exploited successfully, it allows an unauthenticated threat actor to achieve remote code execution (RCE) with root privileges. 

What does this mean for my organization?

While Qualys has responsibly disclosed details of this vulnerability including a working exploit to OpenSSH, multiple third parties have been observed publishing their own proof-of-concept exploits, including tools to automate scanning for potentially vulnerable hosts. 

Although currently time-consuming to exploit, the severity of this vulnerability is considered ‘high’ with a Common Vulnerability Scoring System (CVSS) v3.1 score of 8.1. 

It is important to note that this vulnerability is currently exploitable on 32-bit Linux/glibc systems. Although exploitation on 64-bit systems has not been definitively proven, it is believed to be possible. 

Given the severity of the vulnerability, all users of OpenSSH should familiarize themselves with how it works and mitigate the risk to their organizations. 

How regreSSHion works 

This recently identified vulnerability arises from a signal handler race condition present in specific versions of OpenSSH server (sshd) and is a regression of a previously patched denial-of-service vulnerability (CVE-2006-5051) from nearly two decades ago.  

Although an initial fix addressed CVE-2006-5051 in September 2006, subsequent code changes appeared to reintroduce the vulnerability in the October 2020 release of OpenSSH version 8.5p1. 

This vulnerability stems from how client authentication is handled by sshd and the subsequent asynchronous handling. When a client attempts to connect to sshd, the server waits for a specific duration, the ‘LoginGraceTime’. 

During this period, the server determines if the client can successfully authenticate. If the client fails to authenticate within the specified time, an asynchronous signal handler ‘SIGALRM’ is triggered, allowing the server to perform other tasks. 

In the case of vulnerable versions, the 'SIGALRM' signal handler calls an ‘async-signal-unsafe’ function, which does not behave well asynchronously and can introduce the race condition. 

While exploiting the original vulnerability resulted in a denial-of-service attack, the latest discovery indicates that it could now lead to remote code execution as the ‘root’ user. This is because sshd runs privileged code with full permissions. 

What versions of OpenSSH are vulnerable? 

The following versions of OpenSSH are reportedly vulnerable: 

  • Versions v4.4p1 and earlier (unless patched for CVE-2006-5051 and/or CVE-2008-4109) 
  • Versions v8.5p1 to v9.8p1 (after the regression) 

Versions between v4.4p1 and v8.5p1 are not vulnerable, as are installations on OpenBSD due to their use of an async-signal-safe version of syslog. 

How are hackers scanning for regreSSHion? 

The source code for multiple bulk scanner tools, specifically created to identify potentially vulnerable hosts, is readily available on popular code-sharing websites.  

These tools are written in various programming languages, including Bash, PHP, Python and Rust, with most providing multi-threaded bulk scanning of domains, IP addresses, and entire network ranges. For those that use the popular network mapping utility ‘Nmap’, NSE (Nmap scripting engine) scripts to scan for this vulnerability have also been observed. 

The scanner identifies potentially vulnerable OpenSSH versions based on their service banner when connecting to each target host (usually via port 22, the default SSH port). The retrieved banner is then either compared against a list of static strings or parsed using a regular expression pattern to determine the major, minor, and patch version. 

For example, a banner like SSH-2.0-OpenSSH_8.5p1 would indicate a vulnerable version 8.5p1. 

Most observed vulnerability scanners focus on versions between 8.5p1 and 9.7p1, as indicated by the provided banners in Appendix A. Some tools go beyond this range, identifying earlier vulnerable versions along with determining the operating system version for a more comprehensive result set. 

Given the ease with which these tools can be developed and deployed, identifying potentially vulnerable hosts is straightforward and can easily be leveraged by threat actors equipped with exploit payloads. 

Get started with our world-famous Data Risk Assessment.
Get your assessment

How is regreSSHion exploited? 

Much like the scanner tools, proof-of-concept exploits written in C and Python have been observed on popular code-sharing websites. As news of this vulnerability spreads, these proof of concepts will likely be improved upon in the coming days and weeks. 

When targeting a potentially vulnerable host, the observed exploits typically follow these steps: 

  1. Establish an SSH connection to the target server
  2. Perform the initial handshake
  3. Use heap spraying to send a sequence of packets that manipulate the server’s memory allocation patterns
  4. Measure the server response time to fine-tune the exploit timing
  5. Send a carefully timed packet to exploit the signal handler race condition
  6. Once successfully exploited, deliver a shellcode payload for privileged execution 

Qualys reported that in their experiments, it took approximately 10,000 attempts to successfully “win” the race condition due to the need for precise timing. 

Depending on the target host’s operating system and the server’s ‘LoginGraceTime’, this process could take hours or even days to achieve remote code execution. Once achieved, the consequences could be severe. 

What are hackers saying about regreSSHion? 

As expected, users of underground hacking forums have taken note of CVE-2024-6387 and conversations about potential collaborations to enhance existing proof-of-concept exploits have already begun. 


While it remains uncertain whether these forum users have the ability to create an effective exploit, it is highly likely that high-sophistication threat actors are already working to leverage this vulnerability and add to their arsenals. 

In addition to the freely available proof-of-concept (PoC) code, attackers have the opportunity to purchase a ‘working variant’ for a fraction of a Bitcoin.


Given the relatively low price, around $146, it is likely that these sales, along with similar ones, aim to capitalize on increased interest and take advantage of buyers rather than offering anything notably improved over the publicly available proof of concepts. 

How can I stay protected? 

Given the potential severity of this vulnerability being exploited in the coming day, consider the following to reduce the attack surface and mitigate the potential threat from this vulnerability: 

  • Patching/updating all vulnerable OpenSSH installations to ensure they are up-to-date 
  • Favor the use of key-based, rather than password-based, authentication to negate the need for the ‘LoginGraceTime’ period  
  • If using password-based authentication, reduce the ‘LoginGraceTime' to reduce the time in which a threat actor can attempt their exploit 

Following security best practices can also help to blunt the impact of this attack, which includes: 

  • Monitoring logs for anomalous activity, in this instance SSH login failures and unexpected connections 
  • Use network segmentation to limit SSH host access to trusted networks 

Identifying a vulnerable system

You can discover if you’re using vulnerable OpenSSH versions by checking the service banner. The following OpenSSH server service banners are indicative of vulnerable deployments and are targeted by many of the readily available bulk scanner tools: 

  • SSH-2.0-OpenSSH_8.5p1 
  • SSH-2.0-OpenSSH_8.6p1 
  • SSH-2.0-OpenSSH_8.7p1 
  • SSH-2.0-OpenSSH_8.8p1 
  • SSH-2.0-OpenSSH_8.9p1 
  • SSH-2.0-OpenSSH_9.0p1 
  • SSH-2.0-OpenSSH_9.1p1 
  • SSH-2.0-OpenSSH_9.2p1 
  • SSH-2.0-OpenSSH_9.3p1 
  • SSH-2.0-OpenSSH_9.4p1 
  • SSH-2.0-OpenSSH_9.5p1 
  • SSH-2.0-OpenSSH_9.6p1 
  • SSH-2.0-OpenSSH_9.7p1 

What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:


Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.


See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.


Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

The Definitive Guide to Cryptographic Hash Functions (Part 1)
Give me any message and I will create a secret code to obscure it. Try it! “This really opened my eyes to AD security in a way defensive work never...
data-security-compliance-and-datadvantage,-part-ii:- more-on-risk-assessment
Data Security Compliance and DatAdvantage, Part II:  More on Risk Assessment
I can’t really overstate the importance of risk assessments in data security standards. It’s really at the core of everything you subsequently do in a security program. In this post...
data-security-compliance-and-datadvantage,-part-iii:- protect-and-monitor
Data Security Compliance and DatAdvantage, Part III:  Protect and Monitor
At the end of the previous post, we took up the nuts-and-bolts issues of protecting sensitive data in an organization’s file system. One popular approach, least-privileged access model, is often...
data-security-compliance-and-datadvantage,-part-i:- essential-reports-for-risk-assessment
Data Security Compliance and DatAdvantage, Part I:  Essential Reports for Risk Assessment
Over the last few years, I’ve written about many different data security standards, data laws, and regulations. So I feel comfortable in saying there are some similarities in the EU’s...