CVE-2026-46387 in Suricata
Summary
by MITRE • 09/10/2026
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, Suricata's HTTP/2 decompression path could grow the decompressed response-body buffer without an effective upper bound. A crafted HTTP/2 DATA payload using a high compression ratio, such as gzip, deflate, or brotli compressed data, could cause Suricata to allocate excessive memory while decompressing the payload. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, disable HTTP2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Suricata versions prior to 7.0.16 and 8.0.5 represents a critical resource exhaustion flaw within the network security monitoring engine's handling of Hypertext Transfer Protocol version two traffic. Suricata serves as a high-performance Intrusion Detection System, Intrusion Prevention System, and Network Security Monitoring tool, relying heavily on its ability to parse and inspect various application layer protocols in real time. The specific defect resides in the HTTP/2 decompression subsystem, which is responsible for expanding compressed data streams into readable formats for further inspection by detection rules. This component failed to enforce a strict upper bound on the size of the decompressed response body buffer during processing. Consequently, when Suricata encountered an HTTP/2 DATA frame containing content encoded with high-ratio compression algorithms such as gzip, deflate, or brotli, it would allocate memory proportional to the potential uncompressed size rather than limiting allocation based on configured thresholds or safe limits.
This architectural oversight allows a malicious actor to craft specific HTTP/2 payloads that exploit the disparity between compressed and decompressed data sizes. By sending traffic with an exceptionally high compression ratio, an attacker can trigger the engine to consume excessive amounts of system memory during the decompression phase. This behavior aligns closely with Common Weakness Enumeration category CWE-789, which describes Memory Allocation with Excessive Size Value, as well as CWE-400 regarding Uncontrolled Resource Consumption. The operational impact is severe, potentially leading to a Denial of Service condition where the Suricata process consumes all available system memory or triggers an out-of-memory kill by the operating system kernel. In environments where Suricata operates in inline Intrusion Prevention mode, this could result in network connectivity loss for downstream traffic due to the failure of the security engine to maintain its state and forwarding capabilities.
The vulnerability is particularly dangerous because it can be triggered remotely over standard HTTP/2 connections without requiring authentication or prior interaction with other system components. Attackers can target public-facing web servers monitored by Suricata, injecting maliciously crafted responses that are then processed by the IDS/IPS engine itself rather than just passing through to a client. This transforms what might appear as normal web traffic into an attack vector against the security infrastructure. The flaw underscores the risks associated with trusting external data inputs for memory allocation decisions without rigorous validation of decompressed sizes relative to system resources or predefined limits.
To mitigate this risk, organizations running affected versions must upgrade immediately to Suricata version 7.0.16 or later, which includes patches that enforce proper bounds checking on decompression buffers. For environments where an immediate upgrade is not feasible due to operational constraints or testing requirements, the recommended workaround is to disable HTTP/2 support within the Suricata configuration file by setting http2.enabled to false in the relevant protocol detection rules. This prevents the engine from attempting to parse and decompress HTTP/2 traffic, thereby eliminating the attack surface associated with this specific memory allocation flaw. Additionally, implementing rate limiting on incoming connections and monitoring system resource usage can provide early warning signs of such exploitation attempts before they lead to a complete service outage.