EUVD-2026-98828
GHSA-28w8-qvww-f539
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExecute userspace code in HVM/PVH guest
-
ExploitConfigure single-stepping and branch tracing
-
ExecutionTrigger intercepted #DB while blocked by STI/MovSS
-
ImpactVMEntry fails, crashing the guest
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Type safety enforcement
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an HVM or PVH guest running on VMX hardware virtualization extensions (Intel, VIA, or Zhaoxin CPUs); PV guests and AMD/Hygon/Arm systems are not exploitable. Within such a guest, unprivileged userspace code must arrange the precise CPU state that triggers the bug: an intercepted debug exception (#DB) while single-stepping is active, execution is blocked by STI/MovSS, and branch tracing is enabled. Limiting factors: the narrow hardware requirement, the need for this exact and unusual debug-state combination (high complexity), and the fact that impact is limited to the attacker crashing their own guest rather than the host or neighboring guests. |
| Impact | All exploitation signals point to a low-priority, guest-confined issue despite affecting all Xen versions. No CVSS vector, EPSS, KEV listing, or POC was provided, so there is no evidence of exploitation probability or active abuse (no public exploit identified at time of analysis). The vendor-confirmed impact is narrow: HVM/PVH guest userspace code can crash only its own guest (self-inflicted Denial of Service) with no confidentiality, integrity, host, or cross-guest effect. Exploitation is further constrained to Intel/VIA/Zhaoxin VMX hardware and requires assembling a very specific CPU debug state (intercepted #DB + single-stepping + blocked-by-STI/MovSS + branch tracing), implying high attack complexity. This is a hardening/correctness fix rather than an urgent security emergency; in multi-tenant clouds a tenant can only crash their own VM, which they could already do by other means, so real-world risk is low. Note: no official CVSS was supplied, so the severity characterization here is inferred from the vendor impact statement, not confirmed by NVD. |
| Exploit ScenarioDerived | A malicious or buggy unprivileged process inside an Intel-based HVM/PVH Xen guest programs the specific combination of CPU debug state (single-stepping and branch tracing with an intercepted #DB while blocked by STI/MovSS) that causes a fatal VMEntry failure, crashing its own guest. No public exploit code exists, and the impact is confined to a denial of service of that single guest with no effect on the host or other guests. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Guest-triggered denial of service in Xen Hypervisor lets unprivileged code inside an HVM or PVH guest crash that guest by forcing a VMentry failure; only hosts using Intel, VIA, or Zhaoxin VMX hardware virtualization are exposed, while AMD, Hygon and Arm hosts and PV guests are unaffected. Exploitation requires a high-complexity, precisely arranged CPU state (an intercepted #DB while single-stepping, execution blocked by STI/MovSS, and branch tracing enabled), it is confined to the attacker's own guest rather than the host or other guests, and no public exploit identified at time of analysis. Per the assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) this is a low-priority, guest-confined availability issue affecting all Xen versions on VMX platforms.
RemediationAI
Apply the vendor patches: xsa518.patch for xen-unstable and Xen 4.21.x (SHA-256 a703af59b22f1e47543af0668c8715b4e4011ba4fc05fd8b94bf05503dce88ef) and xsa518-4.20.patch for Xen 4.20.x down to 4.17.x (SHA-256 a1a1b3548166e051f62a0759af5df8d365f524ae52f4bbbe642d45692a1f8bde); the Xen Project advises downstreams on released branches to update to the tip of the relevant stable branch before applying, since release tarballs may not patch cleanly. Security groups that accepted the embargo-period deployment guidance should patch or mitigate immediately even on public-facing hosts with untrusted guests. If patching must be deferred, the documented mitigations are to run only PV guests, which removes the vulnerable VMX path but forfeits HVM/PVH features and hardware-assist performance, or to run HVM guests only on AMD or Hygon hardware, which is safe only where the workload can be migrated to non-VMX hosts. There is no configuration-file switch or Xen command-line option that selectively disables branch tracing or #DB interception per guest that the advisory identifies as an equivalent fix; running mixed unpatched HVM workloads on Intel/VIA/Zhaoxin hardware remains exposed. The advisory is at https://seclists.org/oss-sec/2026/q4/146.
Affected ProductsAI
All versions of Xen Hypervisor are affected, but only when running on hosts with VMX hardware virtualization extensions - Intel, VIA, or Zhaoxin CPUs. The exploitable configuration is limited to HVM and PVH guests; PV guests cannot leverage the vulnerability because they do not traverse the VMX VM-entry path, and AMD, Hygon and Arm systems are unaffected because they use different virtualization extensions. No CPE strings were supplied with the source data. The original advisory (XSA-518 v2, CVE-2026-79611) is published at https://seclists.org/oss-sec/2026/q4/146, and the attached patches are scoped to xen-unstable/Xen 4.21.x and to Xen 4.20.x back through Xen 4.17.x, so users on older stable branches should confirm coverage with their downstream Xen packager.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in Xen's VMX (Intel VT-x style) VM-entry state handling. VM-entry consistency checks reject a state combination that is actually legitimate: a debug exception (#DB) is intercepted by Xen, single-stepping (TF) is active, and the guest is blocked by STI or MovSS interrupt shadowing. XSA-308 already added an adjustment to paper over that case, but a further sub-case exists when branch tracing (hardware branch trace / LBR-style tracing) is enabled - the pre-existing adjustment is still wrong for that sub-case, so the VM-entry attempt fails and the failure is fatal to the guest. The root cause class is an incomplete special-case handling of an unusual but architecturally valid CPU state in the hypervisor's VMX entry path (no CWE identifier was provided in the advisory data; the weak point is best characterized as improper handling/checking of an unusual condition, approximately CWE-754/CWE-703). Scope is strictly the virtualization layer on VMX hardware: PV guests never go through this path, and AMD/Hygon (SVM) and Arm systems use different entry logic entirely. No CVSS vector or CWE was supplied by the vendor; the authoritative independent assessment scores it AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, matching the advisory's statement that only guest availability is affected.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attacker must run code inside the guest (AV:L, PR:L) and assemble an unusual debug-state combination (AC:H); only guest availability is impacted (A:H), no C/I, guest-confined (S:U).
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
2Description PRE-NVD
Executive ViewAI
CVE-2026-79611 is a high-severity availability flaw in the Xen Hypervisor that allows code already running inside an HVM or PVH guest to crash that same guest on hosts using Intel, VIA, or Zhaoxin VMX virtualization. Because the fault is contained to the attacker's own virtual machine and requires a difficult, precisely staged CPU condition, the risk to production workloads is limited to self-inflicted guest outages rather than host compromise or lateral impact on neighboring tenants. Leadership should care mainly where untrusted or multi-tenant HVM/PVH guests run on Intel-based virtualization fleets, since those guests can be taken down at will by their own occupants and no vendor patch is currently available.
No vendor-released patch identified at time of analysis. Interim mitigations: move eligible guests from HVM/PVH to PV, restrict and monitor who can launch or control HVM/PVH guests, segregate untrusted guests onto dedicated hosts, and migrate workloads to unaffected AMD, Hygon, or Arm hosts where available; patch promptly once the vendor advisory provides a fix.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB