Xen Hypervisor EUVD-2026-42607

Exploitation requires the attacker to already be executing code within a Xen guest domain running on an affected, unpatched host - the CVSS 4.0 vector is AV:L (local), so there is no remote network entry point; the guest itself is the launch position. The exact triggering feature, guest configuration, or hypervisor code path is documented in XSA-489 but was not included in the provided intelligence, so the precise configuration prerequisite cannot be named from this data alone and should be confirmed against the advisory. Limiting factors that reduce real-world risk: the attacker must first obtain a guest foothold (making single-tenant, all-trusted-guest deployments substantially lower risk), exploitation is local rather than network-reachable, and only Xen versions/configurations enumerated in XSA-489 are affected.

The provided CVSS 4.0 base score is 9.4 (Critical) with vector AV:L/AC:L/AT:N/PR:N/UI:N and full vulnerable- and subsequent-system impact, indicating that an attacker already positioned locally on the host (in practice, running code inside a guest domain) can, with low complexity and no user interaction, achieve total compromise of the host and neighboring guests. The AV:L (local) vector is the key limiting factor: this is not remotely exploitable across the network against an exposed service, so mass, internet-wide exploitation is unlikely; the realistic threat model is a malicious or already-compromised tenant in a shared/multi-tenant deployment. No EPSS score, no KEV listing, and no POC were provided, so exploitation probability signals are absent rather than low - treat 'no exploit identified' as absence of data, not proof of safety. Note a discrepancy to verify: the vendor vector uses PR:N, but a guest-to-host escalation inherently requires the attacker to first control a guest, which is arguably a privilege prerequisite - defenders should read PR:N as 'no additional privilege beyond an ordinary guest foothold.' Overall this is a genuine high priority for anyone running untrusted or semi-trusted guests on Xen, and lower priority for single-tenant deployments where all guests are already trusted.

An attacker who has gained code execution inside a Xen guest domain - for example a legitimate but malicious tenant on a shared virtualization host, or an adversary who first compromised a guest through an unrelated flaw - invokes the vulnerable, over-privileged code path to escape guest isolation. Leveraging the low attack complexity and no required user interaction, they escalate to the hypervisor/host, gaining the ability to read, tamper with, or disrupt every other guest on that host. No public POC was provided at time of analysis, but the CVSS AV:L/AC:L profile indicates exploitation is straightforward once a guest foothold exists.