CVE-2026-63448: Suricata SMB Parser DOS Vulnerability

CVE-2026-63448 Overview

CVE-2026-63448 is a resource exhaustion vulnerability [CWE-400] in Suricata, the open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring engine. The flaw affects the Server Message Block (SMB) parser in versions prior to 7.0.17 and 8.0.6. The parser retains force-completed transactions on flows where Suricata observes payload in only one direction, including async-oneside flows. Sustained one-directional SMB traffic causes unbounded per-flow state growth, leading to CPU and memory exhaustion on the sensor.

Critical Impact
Attackers can exhaust CPU and memory on Suricata sensors by sending sustained one-directional SMB traffic, degrading or disabling network monitoring and inline protection.

Affected Products

Suricata versions prior to 7.0.17 (7.x branch)
Suricata versions prior to 8.0.6 (8.x branch)
Deployments processing SMB traffic in IDS, IPS, or NSM modes

Discovery Timeline

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

Technical Details for CVE-2026-63448

Vulnerability Analysis

The vulnerability resides in the SMB parser implemented in rust/src/smb. Suricata tracks SMB transactions per flow and enforces an upper bound defined by SMB_MAX_TX. When Suricata sees payload in only one direction of a flow, transaction cleanup waits for inspection in the unseen direction that never arrives. Force-completed transactions accumulate rather than being removed. The transaction creation paths can exceed the intended SMB_MAX_TX bound, and cleanup logic repeatedly scans the growing list. This produces quadratic work as the transaction list expands, amplifying CPU cost per additional packet processed on the same flow.

Root Cause

The root cause is a cleanup precondition mismatch. Cleanup requires bidirectional inspection progress before evicting completed transactions, but async-oneside and one-directional flows never satisfy that precondition. The STREAM_ASYNC condition was not treated as a stream disruption event, so parsers continued to allocate state indefinitely. Combined with the missing hard-fail on transaction creation once SMB_MAX_TX is reached, the parser accepted unbounded new transactions on the affected flows.

Attack Vector

An unauthenticated remote attacker sends sustained SMB traffic in a single direction toward or through a network segment monitored by Suricata. The attacker does not need a valid SMB peer or a completed handshake, since async-oneside flows are sufficient to trigger the condition. As transactions accumulate per flow, both memory footprint and per-packet processing time grow, eventually starving the sensor of resources and producing packet drops or process termination.

rust

// Patch excerpt: introduce STREAM_ASYNC and treat it as a disruption
// Source: https://github.com/OISF/suricata/commit/7ec9d72d28b9370712cf77a5b9d40d6b5db27cb4

// rust/ffi/src/lib.rs
pub const STREAM_GAP: u8 = 0x10;
pub const STREAM_DEPTH: u8 = 0x20;
pub const STREAM_MIDSTREAM: u8 = 0x40;
/// stream is async : packets are seen in only one direction.
pub const STREAM_ASYNC: u8 = 0x80;

// src/app-layer-parser.c
// Before:
// #define IS_DISRUPTED(flags) ((flags) & (STREAM_DEPTH | STREAM_GAP))
// After:
#define IS_DISRUPTED(flags) ((flags) & (STREAM_DEPTH | STREAM_GAP | STREAM_ASYNC))

The complementary fix in commit 755d6c3 updates rust/src/smb/dcerpc.rs and rust/src/smb/files.rs to fail transaction creation once the SMB_MAX_TX limit is reached, preventing unbounded growth of the per-flow transaction list.

Detection Methods for CVE-2026-63448

Indicators of Compromise

Sustained SMB traffic (TCP/445 or TCP/139) observed in only one direction on a monitored flow
Suricata stats.log showing rising app_layer.tx.smb counters without matching bidirectional progress
Increasing capture.kernel_drops or flow_mgr pressure metrics on the sensor
Suricata process consuming abnormally high CPU or resident memory tied to SMB flows

Detection Strategies

Alert on asymmetric SMB flows where server-to-client bytes remain zero while client-to-server bytes grow beyond a defined threshold.
Monitor Suricata EVE JSON stats events for anomalous growth in SMB transaction counts per flow.
Correlate sensor resource pressure with SMB flow volume to identify parser-driven exhaustion versus generic traffic spikes.

Monitoring Recommendations

Ingest Suricata stats.log and EVE telemetry into a centralized analytics platform for baseline and anomaly detection.
Track sensor-level CPU, memory, and packet-drop metrics alongside per-protocol transaction counts.
Configure alerts when a single flow accounts for a disproportionate share of SMB transaction state.

How to Mitigate CVE-2026-63448

Immediate Actions Required

Upgrade Suricata to version 7.0.17 or 8.0.6, which contain the fixes in commits 755d6c3, 7ec9d72, 88adab8, 9a54a04, bc39274, and c8f68b0.
Inventory sensors handling SMB traffic and prioritize upgrades on internet-adjacent and high-throughput deployments.
Review sensor sizing and enable resource pressure alerting until patches are deployed.

Patch Information

The issue is fixed in Suricata 7.0.17 and Suricata 8.0.6. Technical details are documented in GitHub Security Advisory GHSA-hvvj-c8xx-9g35 and OpenInfoSec Issue #8629.

Workarounds

Restrict SMB traffic (TCP/445, TCP/139) at network boundaries so that async-oneside SMB flows cannot reach monitored segments.
Where SMB inspection is not required, disable the SMB app-layer parser in suricata.yaml to remove exposure.
Apply flow timeouts and stream memory caps aggressively to limit per-flow state accumulation on unpatched sensors.

bash

# Example suricata.yaml adjustment: disable SMB parser as a temporary workaround
app-layer:
  protocols:
    smb:
      enabled: no