CVE-2026-63452: Suricata HTTP/1 Parser DoS Vulnerability

CVE-2026-63452 Overview

CVE-2026-63452 is a resource exhaustion vulnerability [CWE-400] in the Suricata network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring engine. The flaw affects Suricata versions 8.0.0 through 8.0.5. The HTTP/1 parser limits decompression work per transaction but does not cap how many small brotli compression bombs a single flow can submit. When response-body-decompress-layer-limit is enabled, repeated compressed responses drive expensive decompression work in rust/htp for every transaction. The result is degraded packet processing and potential loss of monitoring visibility or full denial of service. The Open Information Security Foundation (OISF) fixed the issue in Suricata 8.0.6.

Critical Impact
A remote attacker can exhaust Suricata sensor resources through repeated brotli compression bombs, causing loss of network monitoring visibility and denial of service on the IDS/IPS engine.

Affected Products

Suricata 8.0.0 through 8.0.5
Suricata deployments with response-body-decompress-layer-limit enabled
LibHTP (rust/htp) as bundled with vulnerable Suricata releases

Discovery Timeline

2026-09-18 - CVE-2026-63452 published to the National Vulnerability Database (NVD)
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-63452

Vulnerability Analysis

Suricata's HTTP/1 parser processes compressed response bodies through the LibHTP decompression pipeline in rust/htp. The existing safeguard bounded decompression work at the transaction level. It did not, however, limit how many compression bombs a single flow could submit across multiple transactions.

An attacker who controls, or lures a client toward, an HTTP server can respond to every request with a small brotli-compressed payload that expands aggressively. Each response individually stays under the per-transaction ceiling. Across a single long-lived flow, however, the cumulative decompression cost consumes disproportionate CPU on the sensor.

When response-body-decompress-layer-limit is enabled, the decompression routines in rust/htp execute this expensive work for every transaction. Packet processing on the affected worker degrades, and the sensor can drop packets or miss traffic entirely.

Root Cause

The root cause is missing rate-limiting at the flow scope. The parser enforced per-transaction bounds but had no counter for the total number of compression bombs decompressed within a flow. LibHTP exposed no configuration hook to set a maximum, so operators could not tune the behavior.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker only needs to induce a client behind the Suricata sensor to establish an HTTP/1 flow to an attacker-controlled server. The server then returns repeated brotli-compressed responses within the same flow.

The upstream fix introduces a new LibHTP configuration entry point and a corresponding Suricata rule that fires when the new per-flow limit is reached.

rust

/// Configures the maximum number of compression bombs LibHTP will decompress.
/// # Safety
/// When calling this method, you have to ensure that cfg is either properly initialized or NULL
#[no_mangle]
pub unsafe extern "C" fn htp_config_set_max_nb_compression_bombs(
    cfg: *mut Config, max_bombs: libc::size_t,
) {
    if let Ok(max_bombs) = max_bombs.try_into() {
        if let Some(cfg) = cfg.as_mut() {
            cfg.compression_options.set_max_bombs(max_bombs)
        }
    }
}

Source: Suricata commit 392b6aee

Detection Methods for CVE-2026-63452

Indicators of Compromise

Repeated small brotli-compressed HTTP/1 responses within a single flow from the same server
Sustained high CPU utilization on Suricata worker threads without a corresponding rise in packet rate
Increased capture.kernel_drops or tcp.reassembly_gap counters in stats.log or EVE output
Alerts on Suricata rule sid:2221059 (SURICATA HTTP compression bomb limit reached) after patching

Detection Strategies

Enable the new upstream rule shipped with Suricata 8.0.6 that raises http.compression_bomb_limit_reached and increments http.anomaly.count
Monitor EVE JSON anomaly and stats events for spikes in HTTP decompression-related counters
Correlate flows where the same server returns many compressed responses with unusually high decode time

Monitoring Recommendations

Ingest Suricata eve.json and stats.log into a centralized analytics platform and alert on sudden drops in monitored throughput
Track worker-thread CPU usage per sensor and baseline against normal traffic patterns
Alert on the new app-layer-event:http.compression_bomb_limit_reached event and pivot on the offending flow tuple

How to Mitigate CVE-2026-63452

Immediate Actions Required

Upgrade Suricata to version 8.0.6 on all sensors running any 8.0.x release prior to 8.0.6
Rebuild or repackage Suricata with the patched rust/htp (LibHTP) sources included in 8.0.6
Deploy the updated Suricata rules package so that sid:2221059 is active
Validate sensor health after upgrade using stats.log and packet-drop counters

Patch Information

The fix is available in Suricata 8.0.6. The upstream commits 392b6aee and e369bf29 add the htp_config_set_max_nb_compression_bombs configuration entry point in LibHTP and introduce a new HTTP event, http.compression_bomb_limit_reached, surfaced through rule sid:2221059. Full details are in the GitHub Security Advisory GHSA-j9cx-w9xm-5x84, the Suricata 8.0.6 release notes, and OISF Redmine issue #8694.

Workarounds

Where upgrading is not immediately possible, disable response-body-decompress-layer-limit in suricata.yaml to remove the expensive decompression code path
Constrain HTTP inspection on high-risk sensors until the patched release is deployed
Deploy additional sensors or increase worker-thread counts to absorb transient CPU pressure while patching is scheduled

bash

# suricata.yaml - temporary mitigation until upgrade to 8.0.6
app-layer:
  protocols:
    http:
      enabled: yes
      libhtp:
        default-config:
          # Disable the decompression layer limit path implicated in CVE-2026-63452
          response-body-decompress-layer-limit: 0