CVE-2026-57226: Suricata Buffer Overflow Vulnerability

CVE-2026-57226 Overview

CVE-2026-57226 is a heap buffer overflow [CWE-122] in Suricata, the open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine maintained by the Open Information Security Foundation (OISF). The flaw resides in the HTTP Small Web Format (SWF) decompression path in src/util-file-decompression.c. When the non-default swf-decompression feature is enabled and an unsafe decompress-depth value is configured, Suricata uses the configured depth for allocation instead of restricting to the Flash file's actual data requirement. A crafted SWF response can trigger an integer-related heap buffer overflow and crash the Suricata process. Deployments running default settings are not affected.

Critical Impact
A crafted HTTP response carrying a malformed SWF payload can crash Suricata sensors that enable SWF decompression with an unsafe decompress-depth, degrading network monitoring and IPS coverage.

Affected Products

Suricata versions prior to 7.0.17 (7.x branch)
Suricata versions prior to 8.0.6 (8.x branch)
Deployments with swf-decompression enabled and non-default decompress-depth

Discovery Timeline

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

Technical Details for CVE-2026-57226

Vulnerability Analysis

Suricata's HTTP inspection pipeline includes optional decompression of Adobe Flash SWF payloads to enable pattern matching against the decompressed content. The decompression routine in src/util-file-decompression.c computes a target allocation size from the user-controlled decompress-depth configuration value when that value is non-zero. If an operator configures an oversized decompress-depth, the code path allocates and later writes based on that depth rather than the actual SWF payload length.

An attacker who can serve or relay an HTTP response containing a crafted SWF file across a monitored network segment can cause an integer-related miscalculation followed by an out-of-bounds heap write. The result is a Suricata process crash and loss of visibility until the sensor restarts.

Root Cause

The root cause is improper sizing of the decompression output buffer. The original logic set decompressed_data_len = decompress_depth whenever decompress_depth was non-zero, without bounding it against the actual decompressed_swf_len. Combined with a downstream += 8 addition and buffer allocation, this permits integer-related heap corruption when a hostile configuration is paired with a malformed SWF stream.

Attack Vector

Exploitation requires the target Suricata instance to observe HTTP traffic containing a crafted SWF response while swf-decompression is enabled with an unsafe decompress-depth. No authentication or user interaction on the sensor is required. Attack complexity is elevated because the vulnerable configuration is non-default and depends on operator settings.

// Patch excerpt: src/util-file-decompression.c
// Source: https://github.com/OISF/suricata/commit/82af0aeb7cec39e206a9ca96c4966425eddeaa74

    /* if decompress_depth is 0, keep the flash file length */
-   uint32_t decompressed_data_len = (decompress_depth == 0) ? decompressed_swf_len : decompress_depth;
+   uint32_t decompressed_data_len = decompressed_swf_len;
+   // only restrict the decompressed_data_len, a too big decompress_depth does not make us more
+   // than we need
+   if (decompress_depth > 0 && decompress_depth < decompressed_data_len)
+       decompressed_data_len = decompress_depth;
+
+   // cannot overflow as decompressed_swf_len maxed out at MAX_SWF_DECOMPRESSED_LEN 50000000
    decompressed_data_len += 8;

    /* make sure the inspection buffer has enough space */

The fix caps decompressed_data_len at the smaller of the actual SWF payload length and the configured decompress-depth, and relies on MAX_SWF_DECOMPRESSED_LEN (50,000,000) to preclude the += 8 overflow. See the Suricata patch commit and Pull Request #15704.

Detection Methods for CVE-2026-57226

Indicators of Compromise

Unexpected Suricata process crashes or restarts on sensors performing HTTP inspection.
Segmentation faults or heap corruption entries in Suricata logs, dmesg, or journalctl referencing util-file-decompression.
Gaps in eve.json HTTP or file event output correlated with SWF file transfers.

Detection Strategies

Audit each sensor's suricata.yaml for libhtp configurations that enable swf-decompression alongside a non-zero decompress-depth value.
Correlate Suricata worker restarts with HTTP flows that carry application/x-shockwave-flash responses or files with SWF magic bytes (FWS, CWS, ZWS).
Use configuration-management tooling to identify hosts running vulnerable Suricata versions prior to 7.0.17 or 8.0.6.

Monitoring Recommendations

Monitor Suricata stats.log for sudden drops in packet processing or increased capture.kernel_drops around suspected exploitation windows.
Ship Suricata process telemetry and syslog to a centralized analytics platform to alert on abnormal termination signals (SIGSEGV, SIGABRT).
Alert on HTTP responses delivering SWF content to internal clients, as legitimate SWF traffic is rare on modern networks.

How to Mitigate CVE-2026-57226

Immediate Actions Required

Upgrade Suricata to version 7.0.17 or 8.0.6 as soon as maintenance windows permit.
Inventory all IDS/IPS sensors and confirm the running Suricata build; sensors on default configurations remain unaffected but should still be patched.
If patching cannot be immediate, disable swf-decompression or revert decompress-depth to its default value.

Patch Information

The issue is fixed in Suricata 7.0.17 and Suricata 8.0.6. Additional details are available in GitHub Security Advisory GHSA-p33j-r48q-3jcf and OISF issue #8642.

Workarounds

Disable SWF decompression in libhtp server personalities by setting swf-decompression.enabled: no.
Leave decompress-depth at its default (unset or 0) so the code path derived from actual SWF length is used.
Restrict inbound HTTP responses carrying SWF payloads at the perimeter using web filtering or proxy policies, since Adobe Flash is deprecated.

bash

# suricata.yaml - disable SWF decompression under libhtp
libhtp:
  default-config:
    swf-decompression:
      enabled: no
      type: both
      compress-depth: 0
      decompress-depth: 0

# Validate configuration and restart the service
sudo suricata -T -c /etc/suricata/suricata.yaml -v
sudo systemctl restart suricata