Qualys researchers say an OpenSSH flaw can let attackers remotely compromise servers and allow unauthenticated RCE as root; over 14M servers may be vulnerable
Researchers from Qualys say regreSSHion allows attackers to take over servers with 14 million potentially vulnerable OpenSSH instances identified.
CSOLucian Constantin
Context & Ripple Effects
OpenSSH has previously had to patch flaws that exposed client private keys, including an earlier malicious-server key-leak vulnerability. More recently, research found broad weaknesses in cryptographic keys protecting SSH traffic, underscoring that SSH security depends on both the implementation and operators’ deployed configurations at-risk SSH cryptographic keys.
This report matters because it shifts the immediate concern to server-side exposure: a remotely reachable, unauthenticated path to root access creates a high-priority remediation problem across a large installed base.
First-order effects
Organizations running affected OpenSSH instances must identify exposed servers and apply the available remediation or mitigations; systems left unaddressed risk remote takeover with root privileges.
Qualys’ disclosure gives defenders a concrete basis to prioritize internet-facing SSH services, while also giving attackers a widely relevant target profile.
Second-order effects
Security and infrastructure teams will likely accelerate SSH asset inventories, patch validation, and monitoring for anomalous access on servers that cannot be updated immediately.
The issue raises operational pressure on vendors and managed-service providers to make OpenSSH updates easier to deploy without disrupting authentication and compatibility.
Third-order effects
If recurring SSH implementation and key-management weaknesses persist, secure remote administration will increasingly depend on continuous configuration assurance rather than treating a hardened default as sufficient.
The episode reinforces a broader security-market shift toward prioritizing remediation by reachability and privilege impact: unauthenticated root-level flaws receive attention beyond their nominal software component.
The trend: Critical flaws in foundational remote-access software are making asset visibility, rapid patching, and SSH configuration hygiene core infrastructure-security disciplines.
Pointers on CVE-2024-6387: * Affects OpenSSH 6.2 - 8.8 -> glibc-based Linux * Only x86 POC available * ASLR makes it hard for x64 POC * Upgrade to OpenSSH version 8.9 or later. * Race condition takes a lot of retries - check for multiple exploit attempts on ssh port and block IPs
This OpenSSH RCE advisory is a classic example of hacker craftsmanship, generosity of spirit, & community contribution - a regression of duke's 2006 vuln, inspiration from @lcamtuf's 2001 paper, etc. The legacy of @Qualys' hacker founder @philpraxis continues! 🫡 #hackerhistory [i…
Hi @qualys has it occurred to you that this may not be the best acronym for a cybersecurity product? That it's actually a really bad one, even? [image]
the security bug for #OpenSSH is both rare for it and pretty interesting: https://blog.qualys.com/... and the technical details in https://www.qualys.com/... also, “watch your logs!” — I have a bias here but I have a preference for watching SSH / auth logs 😅
The award-winning Qualys Threat Research Unit (TRU) has discovered a critical vulnerability in OpenSSH, designated CVE-2024-6387 and aptly named “regreSSHion.” This Remote Code Execution bug grants full root access, posing a significant exploitation risk. https://blog.qualys.com/…
Your SSH server should always be restricted to only networks you trust to reduce your risks. If not, well once in a while @qualys finds something like this.
I'll just retweet that. Nice job on OpenSSH. Truth to be told, Qualys might be the only group still regularly doing this kind of “basic stack” research. Almost all the vuln research has shifted elsewhere, largely in response to financial incentives.
If you have a server with SSH open to the internet, patch it NOW. Check it's version, if ssh is between version 4.4p1 and 8.5p1 then you are safe, outside of that patch it right away. If you can't patch it, set LoginGraceTime to 0. This could mean a DDOS but better that then pwnd
OpenSSH bug: yes, it takes forever to exploit against a single host. But you're mostly waiting for a timeout, so you can massively parallelize across internet targets w/o needing a botnet. Assume that this - and not targeted exploitation - is going to be the initial approach.