CVE-2026-45765: Suricata dnp3: unbounded reassembly can lead to resource exhaustion
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, DNP3 reassembly could buffer data without sufficient parser-level bounds. Crafted DNP3 traffic may cause Suricata to consume excessive memory, potentially resulting in denial of service. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, disable DNP3 (which is not enabled by default) if it is not needed, and/or define a limited stream.reassembly.depth (0 or absent is unlimited).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.0.16 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.0.5 - Configuration
Disable DNP3 if it is not needed (DNP3 is not enabled by default).
Suricata DNP3 DNP3 = disable - Configuration
Define a limited stream.reassembly.depth value (use 0 or ensure it is not unlimited) to bound DNP3 reassembly and avoid unbounded resource consumption.
Suricata stream.reassembly.depth = 0 (or absent for unlimited)
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Suricata deployments that process DNP3 traffic are exposed when running a version earlier than 7.0.16 or 8.0.5. DNP3 is not enabled by default, so installations that have not enabled it are not affected through this parser.
What does an attacker need to do to trigger the denial of service?
An attacker can send crafted DNP3 traffic to Suricata. No privileges or user interaction are required, and the traffic can cause excessive memory consumption.
What can be done if upgrading is not immediately possible?
Disable DNP3 if it is not required. Alternatively, configure a finite stream.reassembly.depth value; a value of 0 or an absent setting leaves reassembly unlimited.
Which versions contain the fix?
The issue is fixed in Suricata 7.0.16 and 8.0.5.