All Posts
No items found.
1
min read

RegreSSHion - CVE-2024-6387

Published on
July 8, 2024
Table of Contents

Introduction

OpenSSH is widely known and used software; therefore, the potential risk associated with the regreSSHion vulnerability is a key security factor to consider. As CISOs and analysts race to ensure that their systems are not affected by this vulnerability for compliance and regulatory purposes while simultaneously applying updates to OpenSSH version 9.8p1, we want to provide some information for our customers and the larger community as they traverse these tasks.

This blog will give an overview of the vulnerability, a breakdown of how it can be exploited, and a detection rule to locate the error message associated with regreSSHion. Anomali wants to help our customers detect this vulnerability as they apply the patch provided in the latest version of OpenSSH. Patches and updates can take time, so Anomali customers can use the detection rule in this blog to search for the vulnerability as they work through patching processes.

Overview

On July 1, 2024, the Qualys Threat Research Unit reported their discovery of a remote unauthenticated code vulnerability, registered as CVE-2024-6387, that affects OpenSSH versions up to 4.4p1 and 8.5p1 to 9.7p1 in glibc-based Linux systems.[1] The vulnerability, dubbed regreSSHion, is a signal handler race condition that resides in OpenSSH’s server (sshd). In addition, regreSSHion is a regression of a previously patched vulnerability, CVE-2006-5051, that was reintroduced in October 2020 with OpenSSH version 8.5p1. If successfully exploited, regreSSHion can result in arbitrary code being remoted executed on the affected system.

The impact could be significant given OpenSSH's integration into numerous systems and devices, though widespread exploitation is unlikely due to technical complexities.

Affected OpenSSH versions:

  • Versions before 4.4p1
  • Versions 8.5p1 to 9.7p1

CVE: CVE-2024-6387
Severity: High
CVSS 3.x Score: 8.1
Affected OpenSSH Versions: before 4.4p1; 8.5p1 to 9.7p1
NIST NVD DOP: July 1, 2024

How to Trigger regreSSHion

During SSH authentication, the user has a default time limit of 120 seconds to complete the process. If this time elapses without authentication, the sshd server calls the SIGALRM handler asynchronously.[2] This subsequently causes system-level memory management functions. Therefore, this execution is unsafe for asynchronous operation, and it may cause a race condition under specific conditions. This can lead to memory boundary violations and potentially allow for arbitrary code execution. An attacker would need to make around 10,000 attempts on average, targeting Linux systems using the GNU C Library (glibc) to attempt successful exploitation.[3]

Researchers have been able to reproduce regreSSHion on a 32-bit Linux/glibc system with address space layout randomization (ASLR), however, the attack required 6-8 hours on average with constant, maximum allowed server connections.[4]

Detecting regreSSHion in Security Analytics with Anomali Query Language 

Security Analytics (SA) users can detect the error message associated with the regreSSHion vulnerability with the following Anomali Query Language (AQL) syntax. 

eventlog
| where sourcetype contains_ci "auth.log"
| where message contains_ci "timeout before authentication"
| timechart count by message

 The AQL above searches through the auth.log for the error message ‘timeout before authentication’ that would be present if threat actors were attempting to exploit CVE-2024-6387. SA users simply need to direct this AQL to the correct log source for OpenSSH information.

FEATURED RESOURCES

October 20, 2026
Anomali Cyber Watch

Anomali Cyber Watch: Industrial IoT Attacks & Calendar Phishing

Defensive intelligence brief: Defend against cold storage IoT controller hijacking, escalating Microsoft calendar invite abuse, and CIS government espionage.
Read More
October 21, 2026
Operationalized Threat Intelligence
Cyber Threat Intelligence

The OAuth Trust Gap: Why MFA Cannot Stop a Compromised Application Identity

Read More
October 22, 2026
High-Fidelity Data
Operationalized Threat Intelligence

CISOs Must Govern the Decision Layer, Not Just Run the SOC

CISO role has shifted from overseeing an alert-centric security function to governing the enterprise decision layer on which resilience now depends. In a world defined by cloud complexity, identity sprawl, AI-enabled processes, and machine-speed threats, the traditional SOC model no longer provides enough speed, context, or cohesion.
Read More
Explore All