Xen Hypervisor CVE-2026-79609

Requires the attacker to already control a 64-bit PV-mode guest on a Xen host AND the host's physical memory must extend beyond the 5 TiB boundary (or 3.5 TiB when built with CONFIG_BIGMEM=y), so that the directmap used to read the guest root page table does not cover all memory; XPTI (the Meltdown mitigation) must be active. Limiting factors that reduce real-world exposure: exploitation is local (AV:L) and demands PV mode rather than the now-default HVM/PVH guests, demands uncommon multi-TiB host memory, and requires the attacker to run privileged code inside a guest (PR:L). These conditions make it inapplicable to typical small- and mid-memory Xen deployments.

Signals are mixed and must be weighed carefully. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 8.8) correctly models this as a local, low-privilege attack from within a guest that crosses the scope boundary into the hypervisor - i.e. a guest-to-host escape with full confidentiality, integrity and availability impact, which is the worst class of virtualization bug. However, exploitation probability signals are low: EPSS is only 0.16% (5th percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis, so this is NOT confirmed as actively exploited. The low EPSS is consistent with the narrow preconditions rather than with low impact - the flaw only manifests when a host carries physical memory beyond the 5 TiB boundary (3.5 TiB with CONFIG_BIGMEM=y) and runs 64-bit PV guests with XPTI engaged, a configuration far rarer than default cloud deployments. No SSVC decision record was provided in the input. Net: a genuinely high-impact isolation failure (treat as high priority for operators of large-memory Xen PV hosts) but not a mass-exploitation emergency; the AV:L requirement and the multi-TiB memory precondition meaningfully bound real-world exposure. The input 'Authentication Bypass' tag conflicts with CWE-284 (improper access control) and the described page-table/memory-isolation nature of the bug - treat that tag as unreliable.

An attacker who already controls a 64-bit PV guest on a Xen host with more than 5 TiB of physical memory (or 3.5 TiB under CONFIG_BIGMEM) crafts guest root page tables so that XPTI's copy routine reads guest PTEs through a directmap that does not cover that high memory. The resulting out-of-bounds access lets the guest influence the Xen-chosen page tables actually loaded by hardware, enabling escape from the guest into the hypervisor (scope change) with full read/write and denial-of-service impact. No public proof-of-concept was identified at time of analysis, so exploitation would currently require independent development.