CVE-2026-63448 in Suricata
Summary
by MITRE • 09/19/2026
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to 7.0.17 and 8.0.6, the SMB parser can retain force-completed transactions on flows where Suricata sees payload in only one direction, including async-oneside flows, because cleanup waits for inspection in the unseen direction. The transaction creation paths in rust/src/smb can exceed the intended SMB_MAX_TX bound, and cleanup repeatedly scans the growing list. Sustained one-directional SMB traffic can therefore cause unbounded per-flow state and CPU and memory exhaustion. This issue is fixed in versions 8.0.6 and 7.0.17.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
Suricata serves as a critical component in modern network security architectures, functioning simultaneously as an Intrusion Detection System, an Intrusion Prevention System, and a Network Security Monitoring engine. Its ability to deeply inspect protocol payloads allows organizations to detect malicious activity and enforce security policies at the network layer. However, within this complex ecosystem, specific parsing logic for certain protocols can introduce significant stability risks if not properly bounded by resource constraints. The vulnerability identified in Suricata versions prior to 7.0.17 and 8.0.6 highlights a critical flaw in how the application handles state management during SMB protocol inspection, specifically concerning transaction lifecycle and cleanup procedures.
The core technical deficiency lies within the SMB parser implementation located in the rust/src/smb module of the codebase. Under normal operational conditions, Suricata expects bidirectional traffic flow to properly synchronize request-response pairs for SMB transactions. However, when encountering asynchronous one-sided flows where payload is observed in only one direction, the cleanup mechanism fails to release resources appropriately. Specifically, the system retains force-completed transactions on these flows because the cleanup process incorrectly waits for inspection activity in the unseen direction of the communication stream. This logical error prevents the immediate deallocation of transaction structures that should have been discarded upon completion or timeout.
This retention logic leads directly to a state management failure where the internal list of SMB transactions grows without bound under sustained one-directional traffic conditions. The creation paths for these transactions exceed the intended maximum threshold defined by the SMB_MAX_TX constant, which is designed to limit memory consumption per flow. As new transactions are created and old ones fail to be cleaned up due to the flawed wait condition, the data structure expands continuously. This unbounded growth results in excessive CPU usage as the cleanup routine repeatedly scans an increasingly large list of stale entries, attempting to process them but failing to remove them effectively from memory management structures.
The operational impact of this vulnerability is severe, manifesting primarily as resource exhaustion that can lead to service degradation or complete denial of service for the Suricata instance itself. Sustained one-directional SMB traffic triggers a cycle where memory consumption escalates until system limits are reached, and CPU cycles are consumed by inefficient list scanning operations rather than productive security inspection tasks. This effectively neutralizes the protective capabilities of the IDS/IPS engine on affected systems, potentially allowing other malicious activities to go undetected while the compromised host becomes unresponsive due to resource starvation. From a classification perspective, this flaw aligns with CWE-400, which describes Uncontrolled Resource Consumption, and can be mapped to ATT&CK technique T1496, representing Resource Hijacking where an attacker consumes system resources to disrupt availability or perform denial-of-service attacks against security infrastructure.
Mitigation for this vulnerability requires immediate version upgrades to either Suricata 7.0.17 or 8.0.6, which contain the necessary code corrections to properly handle transaction cleanup in one-sided flows and enforce strict bounds on SMB state retention. In environments where upgrading is not immediately feasible, network segmentation strategies should be employed to limit exposure of Suricata instances to untrusted networks generating high volumes of asymmetric SMB traffic. Additionally, implementing rate limiting for SMB connections can help mitigate the risk by preventing the sustained flow conditions that trigger the resource exhaustion loop until a permanent patch is applied.