CVE-2026-62426
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-62426 is a high-severity Unrestricted Externally Accessible Lock (CWE-412) vulnerability in Xenproject (inferred from references). Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 13th 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 AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-49777
Vulnerability Data
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations…
more
may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. The sysctl issue is CVE-2026-62426. The platform-op issue is CVE-2026-62427.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Access enforcement directly stops external actors from reaching or influencing an internal lock mechanism.
Least privilege limits which subjects may ever touch the lock, reducing the chance of external influence.
Boundary protection prevents external traffic from reaching or manipulating an internally scoped lock.
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.
Vulnerability identification processes can discover externally controllable locks before deployment.
Enforcing least-privilege authorization policies directly prevents external actors from acquiring or influencing locks.
Logical access controls and segmentation stop unintended external influence over synchronization primitives.
Hardened configuration baselines can disable or restrict external lock exposure by default.
Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.
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.
Restricting privileged utilities can limit external lock manipulation but does not address the core weakness.
Privileged access rights limit who can create or manipulate locks, reducing external influence.
Network security measures can block external access paths to locks but do not address the design flaw itself.
Secure development lifecycle practices can prevent introducing externally controllable locks during design.
Application security requirements can mandate that locks remain within the intended control sphere.
Secure architecture principles discourage exposing lock mechanisms to external actors.