Suricata CVE-2026-63452

Exploitation requires that Suricata's response-body-decompress-layer-limit option be enabled - the description explicitly gates the flaw on this configuration. The attacker must also be able to place attacker-influenced HTTP/1 traffic (repeated small brotli compression bombs across many transactions in one flow) in a path the sensor inspects; Suricata is a monitoring engine, so this typically means inducing monitored hosts to fetch from a malicious server rather than connecting to Suricata directly. Limiting factors: affected only in versions 8.0.0-8.0.5 (fixed 8.0.6), the non-default layer-limit configuration requirement, and the need for sustained attacker-controlled compressed HTTP responses; impact is availability/monitoring degradation only, with no confidentiality or integrity effect.

The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) reflects a remote, unauthenticated availability-only impact with no confidentiality or integrity effect - consistent with the CWE-400 resource-exhaustion description. However, this is not a classic remotely-exposed service DoS: Suricata is a passive/inline network sensor, so the 'attacker' does not authenticate to Suricata but instead generates HTTP flows (serving repeated small brotli compression bombs) that the sensor inspects. A critical mitigating signal is the config gate stated in the description - the flaw is only triggerable 'with response-body-decompress-layer-limit enabled,' which is a non-default deployment condition the raw CVSS AC:L does not capture. No EPSS score, KEV listing, or POC was provided in the input; there is no public exploit identified at time of analysis and no evidence of active exploitation, so this is a real but conditional availability risk rather than a confirmed widespread threat. Impact is degradation of monitoring/packet-processing (potential loss of visibility), which for a security-monitoring engine is meaningful but is defensive-tooling impact, not compromise of protected assets.

An attacker who can cause a Suricata sensor to inspect attacker-influenced HTTP/1 traffic (e.g., by luring monitored clients to a malicious server, or on a network segment where responses are observed) serves many small brotli-compressed responses within a single flow. Because Suricata limits decompression per transaction but not the number of compression bombs per flow, each transaction forces expensive decompression in rust/htp, exhausting CPU and degrading packet processing until monitoring visibility is lost or the engine is effectively denied service. No public exploit code was identified in the provided data.