Xen Hypervisor CVE-2026-62426

Exploitation requires the ability to issue sysctl hypercalls to the Xen hypervisor. In a default configuration only the trusted control domain (dom0) can do this, which makes the issue largely moot; the realistic risk arises specifically when XSM/Flask is enabled and used to delegate some sysctl operations to a less-privileged domain, because for some operations the system-wide lock is acquired BEFORE the XSM permission check, and the acquisition is not fair. Limiting factors: the actor must already be a domain with hypercall access (control domain or an XSM/Flask-authorized domain, i.e. PR:L, not remote-unauthenticated), impact is confined to availability (management-operation starvation), and no confidentiality or integrity compromise is demonstrated. A companion issue for platform operations is tracked separately as CVE-2026-62427.

Signals conflict sharply. The input CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:H, base 8.8) claims network reach and full confidentiality/integrity/availability impact, but the description and CWE-412 (Unrestricted Externally Accessible Lock) describe an unfair, permission-check-bypassing acquisition of a system-wide sysctl lock - a resource-exhaustion / denial-of-service condition, not data disclosure or code execution. There is no plausible confidentiality or integrity loss here, so C:H/I:H are overstated; the realistic impact is availability (lock starvation of legitimate control-domain sysctl operations). SSVC corroborates this DoS reading: Exploitation 'none', Automatable 'no', Technical Impact 'total' (total impact fits a hypervisor-wide hang, not exfiltration). EPSS is low at 0.23% (14th percentile), there is no CISA KEV listing, and no public exploit code was provided - consistent with 'no public exploit identified at time of analysis'. Attack vector is effectively local: the actor is a Xen domain issuing hypercalls (control domain or, under XSM/Flask, a deprivileged domain granted sysctl rights), so AV:N is questionable and PR:L is defensible only in an XSM/Flask deployment. Net: this is a real but lower-priority, config-dependent availability issue in Xen, not the 8.8 'critical-ish' remote compromise the raw vector implies - patch on normal cadence, prioritize hosts using XSM/Flask to delegate sysctl/platform operations.

In a Xen deployment using XSM/Flask to grant a semi-trusted domain access to some sysctl operations, that domain repeatedly issues the affected sysctl hypercalls; because the system-wide lock is acquired unfairly and (for some operations) before the XSM permission check, the domain can hoard the lock and starve legitimate control-domain management operations, degrading or hanging host management. No public exploit code is available and CISA SSVC rates exploitation as 'none'.