CVE-2025-52986
Juniper Junos ≤ 21.2
Raw vector
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/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:Y/R:A/V:X/RE:M/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2025-52986 is a medium-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Juniper Junos. Its CVSS base score is 6.8 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 2th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-21144
Vulnerability Data
A Missing Release of Memory after Effective Lifetime vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a local, low privileged user to cause an impact to the availability of the device.…
more
When RIB sharding is enabled and a user executes one of several routing related 'show' commands, a certain amount of memory is leaked. When all available memory has been consumed rpd will crash and restart. The leak can be monitored with the CLI command: show task memory detail | match task_shard_mgmt_cookie where the allocated memory in bytes can be seen to continuously increase with each exploitation. This issue affects: Junos OS: * all versions before 21.2R3-S9, * 21.4 versions before 21.4R3-S11, * 22.2 versions before 22.2R3-S7, * 22.4 versions before 22.4R3-S7, * 23.2 versions before 23.2R2-S4, * 23.4 versions before 23.4R2-S4, * 24.2 versions before 24.2R2, * 24.4 versions before 24.4R1-S2, 24.4R2; Junos OS Evolved: * all versions before 22.2R3-S7-EVO * 22.4-EVO versions before 22.4R3-S7-EVO, * 23.2-EVO versions before 23.2R2-S4-EVO, * 23.4-EVO versions before 23.4R2-S4-EVO, * 24.2-EVO versions before 24.2R2-EVO, * 24.4-EVO versions before 24.4R2-EVO.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.
Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.
Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.
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.
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.
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.
Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.