CVE-2025-3198
Gnu Binutils 2.43 … 2.44
Raw vector
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2025-3198 is a medium-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Gnu Binutils. Its CVSS base score is 4.8 (Medium).
Operationally, ranked at the 18th 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-2 (Flaw Remediation) and AC-6 (Least Privilege) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-9672
Vulnerability Data
A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be…
more
approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly requires applying the vendor patch (ba6ad3a18cb26b79e0e3b84c39f707535bbc344d) that eliminates the memory-leak flaw in display_info.
Restricts installation or execution of objdump (or Binutils) to only those systems that require it, reducing local attack surface for the disclosed vulnerability.
Limits users and processes to the minimum privileges needed to run objdump, thereby constraining the impact of any local memory-leak exploitation.
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 enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.
Runtime monitoring can detect resource exhaustion caused by improper shutdown or release.
Lifecycle management of assets can encompass proper resource release at end-of-life or shutdown.
Capacity management helps surface leaks from unreleased resources but does not prevent the coding flaw.
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 unreleased memory, providing partial coverage of the weakness.
Including restart, recovery and media-handling instructions reduces the likelihood that resources or sensitive data will be left in an exposed or improperly released state after a failure.
Secure development life cycle mandates memory-management practices that reduce missing-release defects.
Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.
Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.
Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.