CVE-2026-23555
Xen ≥ 4.18.0
Raw vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:HSummary
CVE-2026-23555 is a high-severity Reachable Assertion (CWE-617) vulnerability in Xen Xen. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 8th 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-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-23555 affects xenstored, a component of the Xen hypervisor. The vulnerability arises when any guest issues a Xenstore command accessing the illegal node path "/local/domain/", causing a crash due to a clobbered error indicator during node path verification in xenstored. This crash is forced via a failing assert() statement. If xenstored is built with NDEBUG defined, an unprivileged guest accessing this path results in it no longer being serviced by xenstored, while other guests including dom0 continue to be serviced, though xenstored will consume all available CPU time.
An unprivileged guest can exploit this vulnerability with local access, low attack complexity, and no user interaction. Exploitation leads to a denial of service, either by crashing xenstored entirely or, in NDEBUG builds, by causing CPU exhaustion specific to the attacker's requests, as indicated by the CVSS v3.1 base score of 7.1 (AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) and associated CWE-617.
The Xen Project has issued Security Advisory 481 (XSA-481), available at https://xenbits.xenproject.org/xsa/advisory-481.html and http://xenbits.xen.org/xsa/advisory-481.html, detailing the issue. Further discussion appears on the oss-security mailing list at http://www.openwall.com/lists/oss-security/2026/03/17/7.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-14383
Vulnerability Data
Any guest issuing a Xenstore command accessing a node using the (illegal) node path "/local/domain/", will crash xenstored due to a clobbered error indicator in xenstored when verifying the node path. Note that the crash is forced via a failing…
more
assert() statement in xenstored. In case xenstored is being built with NDEBUG #defined, an unprivileged guest trying to access the node path "/local/domain/" will result in it no longer being serviced by xenstored, other guests (including dom0) will still be serviced, but xenstored will use up all cpu time it can get.
- 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 finds reachable assertions during development.
Security engineering principles discourage use of assertions for handling untrusted input.
Validating untrusted inputs structurally prevents attacker data from reaching and triggering assertions.
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 unsafe assertions from being coded in reachable paths.
Runtime monitoring of software can detect assertion-triggered crashes as adverse events.
Vulnerability identification processes can discover and record reachable-assertion flaws before deployment.
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 reachable assertions before release, reducing the likelihood of exploitation.
Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.
Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.
Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.