CVE-2025-64334: 
Suricata vulnerability analysis and mitigation

CVE-2025-64334 is a denial-of-service vulnerability in Suricata, the open-source network IDS, IPS, and NSM engine developed by OISF, caused by unbounded memory growth during HTTP data decompression. It affects Suricata versions 8.0.0 through 8.0.1 (i.e., >= 8.0.0, < 8.0.2). The vulnerability was disclosed on November 26, 2025, and patched in version 8.0.2. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). In the affected versions, the BlockingCursor struct in Suricata's Rust-based HTP decompressor used a Cursor<Vec<u8>> (a dynamically growable buffer) instead of a fixed-size Cursor<Box<[u8]>>, allowing callers to grow the decompression buffer indefinitely when processing LZMA-compressed HTTP response bodies. This regression was introduced in commit 16fee33. The fix (commit 00f04da) replaces the growable Vec with a fixed-size boxed array of ENCODING_CHUNK_SIZE bytes and corrects the error kind from WouldBlock to WriteZero when the cursor is full (GitHub Commit, GitHub Advisory).

Successful exploitation causes unbounded memory consumption in the Suricata process, potentially leading to service crash or unresponsiveness — a denial-of-service condition. Because Suricata functions as a network security monitoring and intrusion detection/prevention engine, its disruption can blind defenders to ongoing network threats and disable active blocking capabilities. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory, Red Hat).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires no authentication, no user interaction, and is exploitable remotely over the network with low attack complexity, making it trivially triggerable by any attacker who can route HTTP traffic through a monitored network segment. The EPSS score is approximately 0.04%, indicating a low current probability of exploitation in the wild. The vulnerability does not appear in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify network segments monitored by Suricata 8.0.0 or 8.0.1 in IDS/IPS/NSM mode, particularly where HTTP traffic inspection and LZMA decompression are enabled.
2. Craft malicious payload: Construct an HTTP response body that is LZMA-compressed and designed to expand to an extremely large size upon decompression (e.g., a decompression bomb — highly compressible data such as repeated bytes).
3. Deliver payload: Serve the crafted LZMA-compressed HTTP response from an attacker-controlled server, or inject it into a monitored network path, so that Suricata's HTTP decompressor processes it.
4. Trigger unbounded memory growth: Suricata's vulnerable BlockingCursor (backed by a growable Vec) will continuously allocate memory as it decompresses the payload without enforcing any size limit.
5. Achieve denial of service: The Suricata process exhausts available system memory, causing it to crash or become unresponsive, disabling network monitoring and IPS enforcement (GitHub Advisory, GitHub Commit).

• Process: Suricata process (suricata) exhibiting rapidly increasing memory consumption (RSS/VSZ) visible via top, htop, or system monitoring tools.
• Logs: Suricata logs showing errors or crashes related to HTTP decompression; OOM (Out of Memory) killer events in /var/log/kern.log or dmesg referencing the Suricata process.
• Network: Unusual HTTP responses with Content-Encoding: lzma or Content-Encoding: x-lzma headers traversing monitored interfaces, especially with large or anomalous Content-Length values.
• System: Sudden Suricata service restarts or watchdog alerts; system-level memory exhaustion events coinciding with HTTP traffic spikes.

The primary remediation is to upgrade Suricata to version 8.0.2 or later, which contains the fix bounding decompression buffer size. For operators unable to upgrade immediately, two workarounds are available: (1) disable LZMA decompression in the Suricata configuration (note: LZMA decompression is disabled by default, so this primarily affects deployments that have explicitly enabled it), and (2) limit the response-body-limit configuration setting to restrict the maximum amount of response body data Suricata will buffer and decompress (GitHub Advisory, Red Hat).

The vulnerability was disclosed by OISF maintainer jasonish via a GitHub Security Advisory on November 26, 2025, alongside the Suricata 8.0.2 and 7.0.13 release announcements. Red Hat tracked the issue via Bugzilla (Bug 2417387) and assigned it high severity. CISA included it in its weekly vulnerability bulletin (SB25-335). No significant independent researcher commentary or social media discussion has been identified beyond standard vulnerability aggregator coverage (GitHub Advisory, Red Hat Bugzilla, CISA Bulletin).