regreSSHion in Perspective: Was It Worth the Hype

The regreSSHion vulnerability generated a lot of buzz and attention in mid-2024 that has since faded away. That’s in part because there’s no evidence that it was ever exploited. But, I argue it’s simply too dangerous not to patch, and that your vulnerability program needs to be flexible enough so that you can escalate exceptional cases like regreSSHion.

On July 1, 2024, the Qualys Threat Research Unit reported a major vulnerability in OpenSSH—CVE-2024-6387—nicknamed “regreSSHion.” As a Remote Unauthenticated Code Execution (RCE) vulnerability, it was the first of its kind in years for one of the internet’s most foundational services. Because OpenSSH is used for secure remote management on nearly every Linux server—and is often exposed to the internet—an RCE vulnerability could grant attackers complete control over a target system.

Initial estimates suggested more than 14 million potentially vulnerable instances, prompting a wave of concern across the security community. Blogs, news articles, and social media posts buzzed with talk of a looming “doomsday scenario.” Yet, as time passed, concrete evidence of widespread, real-world exploitation failed to emerge.

This leads to several key questions: Did regreSSHion live up to its initial hype? Should organizations still treat it as a priority? What do major vulnerability prioritization methods actually say about its true risk level? In this article, we’ll examine how CVSS, EPSS, and CISA KEV responded to CVE-2024-6387, and why you might still want to patch—despite the apparent absence of large-scale attacks..

CVSS

According to the National Vulnerability Database (NVD), CVE-2024-6387 received a CVSSv3.1 base score of 8.1 (a CVSS base score is a numerical value from 0 to 10 that represents the severity of a vulnerability). At first glance, that sounds quite severe—8.1 is officially rated as HIGH—but keep in mind that roughly 70,000 vulnerabilities in the NVD also have a score of 8.1 or higher. In other words, based on CVSS alone, this vulnerability might not immediately stand out among other high-severity issues.

Let’s break it down and understand exactly how this 8.1 was calculated. CVSS scores are determined using specific metrics (note: in CVSS, a vulnerability’s metric values are called its “vector”). Analysts assign these metrics, and the base score is then automatically calculated.

Regarding impact metrics – Confidentiality; Integrity; Availability – this CVE received the most severe score for all: High. This makes sense because it is an RCE—an attacker can execute arbitrary code on the vulnerable system, effectively taking full control. This is the maximum impact a vulnerability can have.

The Attack Vector, Privileges Required, and User Interaction metrics also received the most severe  scores (Network, None, None, respectively). Again, this aligns with the nature of the vulnerability—it is a remote, unauthenticated RCE requiring no user interaction.

Up until this point, the regreSSHion CVE received all the highest scores, almost guaranteeing it a CRITICAL rating. But then came the “Attack Complexity” metric, which was rated HIGH. Using a CVSS score calculator, we can see that this vulnerability could have scored 9.8 if Attack Complexity had been rated Low instead.

This brings us to the nature of the vulnerability itself: regreSSHion is a complex race condition, requiring 6-8 hours of continuous SSH connection attempts (which are often blocked by various compensating controls). Additionally, it has never been proven to be exploitable in certain scenarios, such as 64-bit systems or non-glibc environments.

From an attacker’s perspective, waiting 6-8 hours might seem tedious, but for a high-value target, that’s nothing. For nation-state attackers, it’s even less of an issue—they have the time and resources to refine exploitation techniques and potentially work around issues like 64-bit implementations.

From a defender’s perspective, you only need to be hacked once to lose the game. So why take the chance that someone will improve the exploitation method? The potential damage is too high. This is why I believe everyone should patch this vulnerability. The 8.1 score is misleading—when prioritizing vulnerabilities, Attack Complexity is often irrelevant. A vulnerability like this should not be deprioritized simply because an attacker has to wait a few hours.

EPSS

EPSS scores are calculated automatically on a daily basis. Let’s review the EPSS score of CVE-2024-6387 from its discovery until early February, 2025:

We can see that it took almost a month for EPSS calculations to “respond” to this CVE. For about two weeks, EPSS estimated the likelihood of exploitation at less than 50%. Then, for a little over a month, the EPSS score remained fairly high at around ~70%. However, on September 14th, the score plummeted to near zero and has stayed there since.

Since EPSS is a machine-learning model trained on vulnerability data from a wide variety of sources, we can’t pinpoint exactly why these score changes occurred. My best guess is that the score initially rose as more articles and reports surfaced about the CVE in the days following its discovery. On the day of disclosure, there was insufficient data for the model to assign a high score. However, as time passed without evidence of real-world exploitation, and as media coverage dwindled, the model likely concluded that this CVE was no longer a significant threat.

CISA KEV

The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities that are confirmed to be actively exploited in the wild. As of March 2025, CVE-2024-6387 has never been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. This means that no one has ever provided concrete evidence of this vulnerability being exploited outside of a controlled lab environment. This aligns with the EPSS score drop and leads to an inevitable conclusion: CVSS might have been correct—Attack Complexity made this vulnerability practically unexploitable in the real world.

So, should we patch it?

Regardless of what any framework tells us, and regardless of the lack of exploitation evidence, I argue that everyone should still patch CVE-2024-6387. The potential risk of an unauthenticated RCE in OpenSSH is too high to ignore. There is always the possibility that someone will eventually develop a reliable exploitation method, giving them control over every exposed Linux server you own.

Conclusion

CVE-2024-6387 (“regreSSHion”) was initially heralded as a doomsday scenario for Linux servers, yet widespread exploitation never materialized. Reviewing the three major vulnerability prioritization methods reveals a few important lessons:

• CVSS: A High Attack Complexity rating can significantly lower a score, even if the potential impact is enormous.
• EPSS: The model is reactive to real-world exploitation data and media coverage. Scores can change dramatically over time.
• CISA KEV: Exclusion from the Known Exploited Vulnerabilities list doesn’t guarantee a vulnerability is safe—it simply means exploitation hasn’t been observed in the wild.

By understanding each scoring framework’s strengths and limitations—and by recognizing that their data is not always up to the minute—organizations can make more informed decisions about patching. RegreSSHion, because of its impact if an exploit was developed, shows that even a seemingly “low-exploitation” vulnerability can carry devastating potential impact, underlining the need for proactive patches and robust security practices.

Key Takeaways

1 – Patch Regardless of Scores: Even if a vulnerability isn’t actively exploited, an unauthenticated RCE in a critical service like OpenSSH is too dangerous to ignore. Sometimes we have to ignore all these prioritization frameworks, therefore every vulnerability prioritization program should have a way to push a vulnerability up to the top of your remediation tasks regardless of scores.

2 – Implement Compensating Controls: regreSSHion is a good demonstration of the importance of compensating controls. A simple SSH lockout mechanism after multiple failed login attempts—already a best practice—would render this vulnerability and many similar ones completely irrelevant.