CVE-2026-63448 is a medium severity (CVSS 5.9) resource exhaustion flaw in the SMB parser of Suricata, the network intrusion detection engine. Sustained one-directional SMB traffic can grow per-flow state without limit and use up CPU and memory on the sensor. The fixed releases are 7.0.17 and 8.0.6.
What's affected
The record says Suricata before 7.0.17 and before 8.0.6. The weaknesses are CWE-400 (uncontrolled resource consumption), CWE-401 (missing release of memory) and CWE-407 (inefficient algorithmic complexity).
The record explains the cause: the SMB parser can keep force-completed transactions on flows where it sees payload in only one direction, including async-oneside flows, because cleanup waits for inspection in the unseen direction. Transaction creation can exceed the intended SMB_MAX_TX bound, and cleanup repeatedly scans the growing list. The result is unbounded per-flow state and heavy CPU and memory use.
The upstream commit referenced in the record changes transaction creation so it refuses to create a transaction once the list is full, and the parser then puts the flow into an error state. The vector is network based, high complexity, no privileges, with availability impact only.
How to check if you're exposed
Check the Suricata version on each sensor.
suricata --build-info | head -3
suricata -V
Versions before 7.0.17 on the 7 line and before 8.0.6 on the 8 line are affected per the record. Then look at sensor health. Rising memory use and high CPU on sensors that watch SMB traffic from tap or span ports with asymmetric routing fit the description.
Whatever the product, a current inventory of what you run is what turns a CVE notice into a quick answer. The Gold page for this CVE tracks how its record changes over time, and the free in-browser dependency scan at gold.safeguard.sh/scan covers the application libraries you ship.
What to do now
- Upgrade Suricata to 7.0.17 or 8.0.6, or the next release in your line.
- Check your sensor placement. Taps that see only one direction of a flow are the exposed case.
- Set memory limits and alerts on sensors so exhaustion raises an alarm.
- Consider restarting sensors on a schedule until you can patch, if memory climbs.
- Confirm a sensor that stopped inspecting is noticed. Monitor the monitor.
Why it matters
Security tools are targets too. A sensor that runs out of memory stops inspecting, and that blind spot is useful to anyone who wants to move unseen. The flaw is not a break-in, but a way to degrade defences.
The root cause is a bound that was not enforced on every creation path, combined with cleanup that waits for traffic that never arrives. Both are common failure modes in stateful network software. The record does not list the CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect sensors that see both directions of traffic?
The record describes flows where payload is seen in only one direction, so those are the exposed case. Upgrading is still the clean fix.
Sources
Last reviewed: 18 October 2026.
