Raw vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HSummary
CVE-2025-51006 is a high-severity Double Free (CWE-415) vulnerability in Broadcom Tcpreplay. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-16 (Memory Protection) and SC-39 (Process Isolation) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-30819
Vulnerability Data
Within tcpreplay's tcprewrite, a double free vulnerability has been identified in the dlt_linuxsll2_cleanup() function in plugins/dlt_linuxsll2/linuxsll2.c. This vulnerability is triggered when tcpedit_dlt_cleanup() indirectly invokes the cleanup routine multiple times on the same memory region. By supplying a specifically crafted pcap…
more
file to the tcprewrite binary, a local attacker can exploit this flaw to cause a Denial of Service (DoS) via memory corruption.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Double free vulnerability in tcprewrite allows local DoS via memory corruption when processing crafted pcap files, enabling endpoint denial of service through application exploitation.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly implements memory protections that block double-free corruption in dlt_linuxsll2_cleanup() before it can cause DoS.
Requires validation of untrusted pcap input to tcprewrite, preventing the malformed file from reaching the vulnerable cleanup path.
Isolates the tcprewrite process so memory corruption from the double-free cannot affect other system components or escalate the DoS.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent double-free errors via static analysis, safe memory APIs, and testing.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect double-free conditions before release.
Secure development life cycle includes memory-safety practices that can prevent double-free bugs.
Application security requirements can mandate memory-safety rules that reduce double-free risk.
Secure system architecture and engineering principles can prescribe safe memory-management patterns.
Secure coding standards directly address proper use of free() and similar functions.