CVE-2025-54514
Raw vector
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/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-54514 is a medium-severity SoC (CWE-1189) vulnerability in Amd (inferred from references). Its CVSS base score is 4.8 (Medium).
Operationally, ranked at the 1th 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 SC-32 (System Partitioning) and SC-4 (Information in Shared System Resources) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-207430
Vulnerability Data
Improper isolation of shared resources on a system on a chip by a malicious local attacker with high privileges could potentially lead to a partial loss of integrity.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
SC-4 explicitly prevents unauthorized information transfer via shared system resources, addressing the core SoC isolation failure.
SC-49 mandates hardware-enforced separation between security domains, directly countering improper SoC resource isolation.
SC-32 requires partitioning the system into separate domains, structurally preventing shared-resource leakage on an SoC.
SC-50 requires software-enforced separation mechanisms that would prevent the described SoC shared-resource weakness.
SC-3 requires isolation of security functions from non-security ones, directly preventing improper sharing of SoC resources between trusted and untrusted agents.
SC-39 enforces separate execution domains for processes, stopping unintended sharing of SoC resources between trust levels.
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.
Contractual requirements on suppliers can mandate proper SoC resource isolation.
Hardware integrity/authenticity checks before acquisition can verify isolation features.
Supplier assessments can evaluate SoC isolation capabilities prior to purchase.
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.
Secure system architecture and engineering principles directly require hardware-level isolation of shared SoC resources.
Security testing can detect SoC isolation issues but does not prevent the weakness from existing in the design.
Privileged access rights can reduce unauthorized software access to SoC resources but do not enforce hardware isolation.
Network security controls can limit external access to SoC resources but do not enforce hardware-level isolation.
Network segregation can reduce exposure of SoC shared resources but does not address internal hardware isolation.
Secure coding practices can mitigate software exploits of SoC isolation flaws but do not prevent the underlying hardware weakness.