CVE-2025-64334: Oisf Suricata DOS Vulnerability

CVE-2025-64334 Overview

CVE-2025-64334 is a resource exhaustion vulnerability in Suricata, the open-source network IDS, IPS, and NSM engine maintained by the Open Information Security Foundation (OISF). Affected versions from 8.0.0 up to (but not including) 8.0.2 fail to bound memory allocation when decompressing HTTP response bodies. Attackers can deliver a compressed HTTP payload that expands without limit during decompression, causing unbounded memory growth in the Suricata process. The flaw maps to [CWE-770: Allocation of Resources Without Limits or Throttling]. OISF has published a fix in version 8.0.2.

Critical Impact

A remote, unauthenticated attacker can exhaust memory on a Suricata sensor by sending crafted compressed HTTP traffic, degrading or disabling network monitoring.

Affected Products

• OISF Suricata 8.0.0
• OISF Suricata 8.0.1
• All Suricata 8.0.x releases prior to 8.0.2

Discovery Timeline

• 2025-11-26 - CVE-2025-64334 published to NVD
• 2025-12-05 - Last updated in NVD database

Technical Details for CVE-2025-64334

Vulnerability Analysis

Suricata inspects HTTP traffic by decompressing response bodies using libhtp. The decompression path in rust/htp/src/decompressors.rs allocates a growable buffer to hold decompressed output. When processing highly compressible content, the decompressed size can exceed the compressed size by orders of magnitude. Without an enforced upper bound, the buffer grows until host memory is exhausted.

The issue is most pronounced with LZMA decompression, where compression ratios can be extreme. Because Suricata typically runs as a long-lived inspection process on a sensor, memory pressure affects packet processing across all monitored flows, not just the offending session.

Root Cause

The underlying buffer used by the blocking cursor was a Vec<u8> allocated with Vec::with_capacity(ENCODING_CHUNK_SIZE), which permitted reallocation and growth beyond the chunk size during decompression. The decompressor did not enforce a maximum decompressed size against response-body-limit for compressed streams.

Attack Vector

An unauthenticated remote attacker sends or induces an HTTP response containing a compression bomb (for example, an LZMA-compressed payload that expands to many gigabytes) across a network segment monitored by Suricata. As Suricata decompresses the body for inspection, its memory consumption grows without limit, leading to denial of service of the sensor.

// Patch excerpt from rust/htp/src/decompressors.rs
// htp: bound decompression
 #[derive(Debug)]
 struct BlockingCursor {
-    pub cursor: Cursor<Vec<u8>>,
+    pub cursor: Cursor<Box<[u8]>>,
 }

 impl BlockingCursor {
     fn new() -> BlockingCursor {
         BlockingCursor {
-            cursor: Cursor::new(Vec::with_capacity(ENCODING_CHUNK_SIZE)),
+            cursor: Cursor::new(Box::new([0u8; ENCODING_CHUNK_SIZE])),
         }
     }

Source: OISF Suricata commit 00f04daa

The fix replaces the growable Vec<u8> with a fixed-size Box<[u8]> of ENCODING_CHUNK_SIZE, preventing unbounded growth of the decompression buffer.

Detection Methods for CVE-2025-64334

Indicators of Compromise

• Sudden, sustained memory growth in the suricata process without a proportional increase in flow count.
• Suricata eve.json events showing repeated HTTP transactions with very large response_body_length values relative to compressed payload size.
• Sensor-level OOM kills or kernel oom-killer log entries terminating Suricata.

Detection Strategies

• Monitor Suricata application metrics (stats.log) for anomalies in http.memuse, http.memcap, and decoder counters tied to compressed bodies.
• Inspect HTTP responses with Content-Encoding: lzma, br, or gzip that declare or yield extreme decompressed-to-compressed size ratios.
• Correlate spikes in host memory utilization with packet-loss counters reported by Suricata capture statistics.

Monitoring Recommendations

• Alert when the Suricata process resident memory exceeds a baseline threshold for the deployment.
• Track the Suricata version inventory across sensors and flag any host running 8.0.0 or 8.0.1.
• Capture and review pcaps from sessions immediately preceding a sensor memory spike to identify potential compression-bomb sources.

How to Mitigate CVE-2025-64334

Immediate Actions Required

• Upgrade all Suricata sensors to version 8.0.2 or later.
• Where immediate patching is not possible, disable LZMA decompression in suricata.yaml.
• Lower response-body-limit under libhtp default-config to bound per-transaction decompression work.
• Review sensor memory headroom and configure host-level cgroup limits to prevent system-wide OOM.

Patch Information

The vulnerability is fixed in Suricata 8.0.2. The corrective change is recorded in commit 00f04daa3a44928dfdd0003cb9735469272c94a1 and described in the OISF GHSA-r5jf-v2gx-gx8w advisory.

Workarounds

• Disable LZMA decompression in the libhtp configuration if the protocol is not required for inspection.
• Set a conservative response-body-limit to cap the volume of body data Suricata will decompress per transaction.
• Restrict Suricata's process memory using systemd MemoryMax or container memory limits to contain impact.

# suricata.yaml mitigation example
libhtp:
  default-config:
    # Cap decompressed response body size
    response-body-limit: 1mb
    # Disable LZMA decompression until upgrade is complete
    lzma-enabled: false
    lzma-memlimit: 1mb