CVE-2024-47188
Executive Summary
CVE-2024-47188 is a high-severity vulnerability in Suricata, a widely used network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine. The vulnerability stems from a missing initialization of the random seed for the "thash" function, which is used for byte-range tracking. This flaw leads to predictable hash table behavior, allowing an attacker to force a disproportionate amount of data into a single hash bucket. The result is severe performance degradation, effectively enabling a denial-of-service (DoS) attack against the Suricata engine. The vulnerability affects all versions prior to 7.0.7 and has a CVSS score of 7.5, indicating high severity. No public proof-of-concept (PoC) or exploit code is currently available, but the risk is significant due to the potential for network-based attacks without authentication.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Suricata is typically distributed as a standalone binary or via package managers (e.g., apt, yum) and is not a library dependency in the same way as NPM, PyPI, Go, or Ruby packages. However, organizations using Suricata as part of a larger security stack (e.g., integrated with Security Information and Event Management (SIEM) systems) should treat this as a critical supply chain risk. The vulnerability can be exploited remotely, and the lack of a patch for older versions (e.g., 6.x) may leave systems exposed if updates are not applied.
CVSS Breakdown & Threat Level
- CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Base Score: 7.5 (High)
- Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely over the network.
- Attack Complexity: Low (AC:L) – No special conditions or complex attack sequences are required.
- Privileges Required: None (PR:N) – No authentication is needed to exploit the vulnerability.
- User Interaction: None (UI:N) – The attack does not require any user action.
- Scope: Unchanged (S:U) – The impact is confined to the vulnerable component.
- Confidentiality Impact: None (C:N) – No data is exposed.
- Integrity Impact: None (I:N) – No data is modified.
- Availability Impact: High (A:H) – The attack can cause severe performance degradation, leading to denial of service.
Threat Level: High. The vulnerability is easily exploitable remotely without authentication, and the impact on availability is significant. While no public exploit exists, the predictable hash behavior can be weaponized with minimal effort.
Deep Dive & Mechanics
The vulnerability lies in the thash function used for byte-range tracking in Suricata. Byte-range tracking is a feature that allows Suricata to reassemble and track specific byte ranges within network flows, often used for file extraction or protocol analysis. The thash function is responsible for hashing data to distribute it across hash buckets for efficient lookup.
In vulnerable versions (prior to 7.0.7), the random seed for the thash function is not initialized. This means the hash function behaves deterministically, producing the same hash values for the same input across different instances or sessions. An attacker can exploit this by crafting network traffic that consistently maps to the same hash bucket. By sending a large volume of such traffic, the attacker can cause a hash collision storm, where all data is forced into a single bucket. This leads to O(n) lookup times instead of O(1), severely degrading performance and potentially causing the Suricata engine to drop packets or crash.
The attack does not require any special privileges or user interaction. The attacker only needs to send specially crafted network packets to the interface monitored by Suricata. The impact is purely on availability, as the engine becomes unable to process traffic efficiently.
Vulnerable vs. Patched Code
The fix in version 7.0.7 involves initializing the random seed for the thash function. Below is a conceptual comparison:
Vulnerable Code (pre-7.0.7):
// thash.c
#include <stdlib.h>
// Missing: srand(time(NULL)) or similar initialization
uint32_t thash(const void *key, size_t len) {
// Deterministic hash due to uninitialized seed
uint32_t hash = 0;
const uint8_t *data = (const uint8_t *)key;
for (size_t i = 0; i < len; i++) {
hash = hash * 31 + data[i];
}
return hash;
}
Patched Code (7.0.7):
// thash.c
#include <stdlib.h>
#include <time.h>
void thash_init(void) {
srand((unsigned int)time(NULL));
}
uint32_t thash(const void *key, size_t len) {
// Randomized hash using seeded random
uint32_t hash = rand();
const uint8_t *data = (const uint8_t *)key;
for (size_t i = 0; i < len; i++) {
hash = hash * 31 + data[i];
}
return hash;
}
The patched version introduces a thash_init() function that seeds the random number generator with the current time, ensuring that hash values are unpredictable across different runs. This prevents attackers from predicting hash bucket assignments.
Exploitation & Lab Setup
Red Team (Attack Simulation)
Objective: Cause denial of service by flooding a single hash bucket.
Prerequisites:
- A target running Suricata < 7.0.7 with byte-range tracking enabled.
- Network access to the monitored interface.
Steps:
- Identify the hash function behavior: Since the seed is uninitialized, the hash is deterministic. For a given input, the hash value is always the same.
- Craft packets with identical byte-range data: Use a tool like
scapyto generate packets that trigger byte-range tracking with the same data. - Send a large volume of packets: Use a high-speed packet generator (e.g.,
hping3ortcpreplay) to send thousands of such packets per second.
Example Python script using scapy:
from scapy.all import *
import sys
target_ip = sys.argv[1]
target_port = 80
# Craft a TCP SYN packet with a specific payload that triggers byte-range tracking
payload = b"A" * 100 # Same payload for all packets
packet = IP(dst=target_ip)/TCP(dport=target_port, flags="S")/Raw(load=payload)
# Send 10000 packets
send(packet, count=10000, inter=0.001)
Expected Outcome: Suricata's performance degrades significantly, potentially causing packet drops or engine crash.
Blue Team (Defense & Detection)
Objective: Detect and mitigate the attack.
Steps:
- Monitor Suricata performance: Use tools like
top,htop, or Suricata's built-in stats to watch for high CPU usage or packet drops. - Enable logging: Configure Suricata to log hash bucket statistics (if available) or enable debug logging for the
thashfunction. - Deploy detection rules: Use the Sigma and Suricata rules provided in the Detection Engineering section.
- Apply patch: Upgrade to Suricata 7.0.7 or later.
Mitigation:
- If patching is not immediately possible, consider disabling byte-range tracking (if not critical) or rate-limiting traffic from suspicious sources.
- Use network segmentation to limit exposure of Suricata to untrusted networks.
Indicators of Compromise (IOCs)
- Network Traffic Patterns:
- High volume of packets with identical payloads targeting the same flow.
- Unusual number of hash collisions detected in Suricata logs (if logging is enabled).
- System Indicators:
- Suricata process consuming 100% CPU.
- High packet drop rate in Suricata stats.
- Engine crashes or restarts.
- Log Entries:
- Suricata logs showing "hash bucket overflow" or similar errors.
- Repeated alerts for the same flow with no variation.
Detection Engineering
YARA Rule
rule CVE_2024_47188_Suricata_Hash_Collision {
meta:
description = "Detects potential exploitation of CVE-2024-47188 via hash collision patterns"
author = "Valters IT"
date = "2025-04-10"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-47188"
strings:
$hash_error = "hash bucket overflow" nocase
$perf_degradation = "performance degradation" nocase
condition:
any of them
}
Sigma Rule
title: Suricata Hash Collision DoS Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential exploitation of CVE-2024-47188 by monitoring for hash bucket overflow errors in Suricata logs.
author: Valters IT
date: 2025/04/10
references:
- https://nvd.nist.gov/vuln/detail/CVE-2024-47188
logsource:
product: suricata
service: suricata
detection:
selection:
EventID: 'alert'
AlertSignature: '*hash bucket overflow*'
condition: selection
falsepositives:
- Legitimate high traffic volumes may cause temporary hash collisions.
level: high
Suricata Rule
alert tcp any any -> any any (msg:"CVE-2024-47188 - Potential Hash Collision DoS"; flow:to_server; content:"|41 41 41|"; depth:3; threshold:type both, track by_src, count 1000, seconds 60; sid:1000001; rev:1;)
Note: The Suricata rule above is a generic example. In practice, you would need to identify the specific byte-range data being targeted. The rule triggers on a high volume of packets with the same payload (e.g., "AAA") from the same source.
Remediation & Mitigation
Immediate Actions:
- Upgrade Suricata: Update to version 7.0.7 or later. This is the only complete fix.
- Disable Byte-Range Tracking: If upgrading is not possible, disable byte-range tracking in the Suricata configuration (
app-layer.protocols.*.byte-range: no). - Rate Limiting: Implement rate limiting on the network edge to limit the number of packets per second from a single source.
Long-Term Measures:
- Regular Updates: Keep Suricata and all security tools up to date.
- Monitoring: Implement continuous monitoring for hash collision anomalies.
- Network Segmentation: Isolate Suricata sensors from untrusted networks where possible.
Workarounds:
- If byte-range tracking is essential, consider using a load balancer to distribute traffic across multiple Suricata instances.
- Apply firewall rules to block traffic from known malicious sources.
Valters IT
Securing Digital Frontiers