CVE-2025-53538: Oisf Suricata HTTP/2 DoS Vulnerability

CVE-2025-53538 Overview

CVE-2025-53538 is a resource exhaustion vulnerability affecting Suricata, the open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine developed by the Open Information Security Foundation (OISF). The vulnerability exists in the HTTP/2 parser component and stems from improper handling of data frames sent on HTTP/2 stream 0, which according to RFC 9113 should never contain application data. This mishandling can lead to uncontrolled memory consumption, ultimately resulting in loss of network visibility—a critical failure mode for security monitoring infrastructure.

Critical Impact

Attackers can exploit this vulnerability remotely without authentication to cause memory exhaustion in Suricata deployments, potentially disabling network security monitoring and intrusion detection capabilities during an active attack.

Affected Products

• OISF Suricata versions 7.0.10 and below
• OISF Suricata version 8.0.0-beta1
• OISF Suricata version 8.0.0-rc1

Discovery Timeline

• July 22, 2025 - CVE-2025-53538 published to NVD
• October 6, 2025 - Last updated in NVD database

Technical Details for CVE-2025-53538

Vulnerability Analysis

This vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption). The issue arises from how Suricata's HTTP/2 parser handles data frames received on stream ID 0. Per the HTTP/2 specification (RFC 9113 Section 5.1.1), stream 0 is reserved for connection-level control frames and should never carry DATA frames. However, vulnerable versions of Suricata failed to properly reject or limit data on this stream, allowing attackers to send malformed HTTP/2 traffic that triggers unbounded memory allocation.

The vulnerability is particularly concerning because it targets network security infrastructure itself. When a Suricata sensor experiences memory exhaustion, it may fail to inspect network traffic, effectively blinding security teams during what could be the most critical moment—an active intrusion attempt. The attack can be executed remotely over the network without any authentication or user interaction required.

Root Cause

The root cause lies in the HTTP/2 parser's failure to validate that DATA frames are not sent on stream 0 as required by the HTTP/2 specification. Additionally, the code incorrectly treated global transactions (those associated with stream 0) as potentially holding files, which led to improper resource tracking and memory allocation. The fix introduces explicit validation to detect and flag data frames on stream 0 as a protocol violation, along with correcting the file handling logic for global transactions.

Attack Vector

An attacker can exploit this vulnerability by sending crafted HTTP/2 traffic to a network segment monitored by a vulnerable Suricata deployment. The attack involves sending HTTP/2 DATA frames on stream 0, which violates the protocol specification. When Suricata receives this malformed traffic, the parser mishandles it, leading to unbounded memory allocation. The attack requires no authentication and can be executed from any network position that can send traffic visible to the Suricata sensor.

The following code shows the security patches applied to address this vulnerability:

HTTP/2 Event Detection Rule Addition:

 alert http2 any any -> any any (msg:"SURICATA HTTP2 reassembly limit reached"; flow:established; app-layer-event:http2.reassembly_limit_reached; classtype:protocol-command-decode; sid:2290015; rev:1;)
 alert http2 any any -> any any (msg:"SURICATA HTTP2 dns request too long"; flow:established,to_server; app-layer-event:http2.dns_request_too_long; classtype:protocol-command-decode; sid:2290016; rev:1;)
 alert http2 any any -> any any (msg:"SURICATA HTTP2 dns response too long"; flow:established,to_client; app-layer-event:http2.dns_response_too_long; classtype:protocol-command-decode; sid:2290017; rev:1;)
+alert http2 any any -> any any (msg:"SURICATA HTTP2 data on stream zero"; flow:established; app-layer-event:http2.data_stream_zero; classtype:protocol-command-decode; sid:2290018; rev:1;)

Source: GitHub Commit - HTTP/2 Stream 0 Detection

Rust Parser Event Enumeration Update:

     ReassemblyLimitReached,
     DnsRequestTooLong,
     DnsResponseTooLong,
+    DataStreamZero,
 }

 pub struct HTTP2DynTable {

Source: GitHub Commit - Event Type Addition

Global Transaction File Handling Fix:

         self.tx_id += 1;
         tx.tx_id = self.tx_id;
         tx.state = HTTP2TransactionState::HTTP2StateGlobal;
-        tx.tx_data.update_file_flags(self.state_data.file_flags);
-        // TODO can this tx hold files?
-        tx.tx_data.file_tx = STREAM_TOSERVER|STREAM_TOCLIENT; // might hold files in both directions
-        tx.update_file_flags(tx.tx_data.file_flags);
+        // a global tx (stream id 0) does not hold files cf RFC 9113 section 5.1.1
         self.transactions.push_back(tx);
         return self.transactions.back_mut().unwrap();
     }

Source: GitHub Commit - File Flags Fix

Detection Methods for CVE-2025-53538

Indicators of Compromise

• Unusual memory growth patterns in Suricata processes without corresponding increase in legitimate traffic volume
• HTTP/2 connections containing DATA frames with stream ID 0 in network packet captures
• Suricata log entries indicating http2.data_stream_zero events after applying detection signatures
• Unexplained gaps in IDS/IPS alert coverage or flow logging during periods of network activity

Detection Strategies

• Deploy the vendor-recommended detection signature: drop http2 any any -> any any (frame:http2.hdr; byte_test:1,=,0,3; byte_test:4,=,0,5; sid: 1;) which tests for HTTP/2 DATA frame type with stream ID 0
• Monitor Suricata process memory utilization with alerting thresholds for anomalous growth patterns
• Enable the http2.data_stream_zero app-layer event detection in updated Suricata versions (7.0.11+ and 8.0.0+)
• Implement network-level logging to capture HTTP/2 frame details for forensic analysis

Monitoring Recommendations

• Configure system-level monitoring for Suricata memory usage with automated alerting when thresholds are exceeded
• Enable Suricata statistics logging (stats.log) to track HTTP/2 parser anomalies and resource utilization trends
• Implement redundant network monitoring coverage to detect security visibility gaps if primary Suricata sensors fail
• Review HTTP/2 traffic patterns for connections that deviate from normal protocol behavior

How to Mitigate CVE-2025-53538

Immediate Actions Required

• Upgrade Suricata to version 7.0.11 or 8.0.0 immediately to address this vulnerability
• If immediate patching is not possible, implement the detection signature to drop malicious traffic as a temporary mitigation
• Review Suricata deployment architecture to ensure redundant monitoring coverage in case of sensor failure
• Audit recent logs for signs of exploitation attempts or unexplained resource consumption events

Patch Information

OISF has released patched versions of Suricata that address this vulnerability. Users should upgrade to version 7.0.11 for the 7.x branch or version 8.0.0 for the 8.x branch. The fixes are documented in the GitHub Security Advisory GHSA-qrr7-crgj-cmh3. The patches introduce proper validation for HTTP/2 stream 0 data handling and correct the file flag behavior for global transactions.

Workarounds

• Disable the HTTP/2 parser entirely in Suricata configuration if HTTP/2 monitoring is not critical to your environment
• Implement the inline blocking signature provided in the advisory to drop malicious HTTP/2 traffic before it reaches the vulnerable parser
• Consider deploying upstream network filtering to block suspicious HTTP/2 traffic patterns before they reach Suricata sensors
• Enable resource limits for the Suricata process at the operating system level to prevent complete system resource exhaustion

# Suricata configuration workaround - Disable HTTP/2 parser
# In suricata.yaml, locate the app-layer protocols section and disable http2:

app-layer:
  protocols:
    http2:
      enabled: no

# Alternative: Deploy detection/blocking signature
# Add to local.rules or appropriate rules file:
drop http2 any any -> any any (msg:"CVE-2025-53538 HTTP2 Stream 0 Data Attack"; frame:http2.hdr; byte_test:1,=,0,3; byte_test:4,=,0,5; sid:2025535381; rev:1;)