QEMU CVE-2026-81627

Requires an attacker with privileged (root-equivalent) access already inside a QEMU guest running specifically on a Q35 machine type with the KVM accelerator, where the VAPIC device path is in use. Exploitation is local to the guest (no network vector) and needs no user interaction on the host. Limiting factors: the attacker must first hold privileged guest access (PR:H), the target must be the Q35/KVM configuration rather than another machine type, and success depends on the guest being able to invoke the VAPIC setup hypercall - so this is a multi-tenant/hostile-tenant escape scenario, not a remote or unauthenticated exposure.

This is a genuinely high-severity issue whose real-world risk is bounded by a demanding precondition. The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, 8.2) is internally consistent with the description: exploitation is local to the guest (AV:L), requires a privileged guest user (PR:H), and crosses a security boundary (S:C) by escaping guest isolation into System Management Mode - the most privileged x86 execution context - yielding total confidentiality, integrity, and availability impact on the host/firmware. SSVC corroborates this: Technical Impact 'total', but Automatable 'no' (the attacker needs pre-existing privileged guest access and a specific chipset/emulation path, not a mass-scannable network entry point), and Exploitation only 'poc'. EPSS is low at 0.20% (10th percentile), and there is NO CISA KEV listing, so this is publicly-known-fragile rather than widely-exploited - priority should be driven by the total technical impact and multi-tenant blast radius, not by imminent mass exploitation. The one caveat to verify: SSVC marks exploitation as 'poc' but no public exploit URL is present in the provided references (only Red Hat/QEMU tracker links), so treat 'proof-of-concept exists' as vendor-asserted rather than independently confirmed here.

A malicious or compromised root/privileged user inside a Q35/KVM guest issues the VAPIC setup hypercall with parameters that place the writable RAM alias outside the option ROM window, overlapping locked SMRAM. Because QEMU does not bounds-check the alias against the ROM window, the guest writes past the intended region into SMM memory despite chipset D_LCK protection, injecting code that later executes in System Management Mode. SSVC indicates proof-of-concept-level exploitation exists, though no public exploit link is in the provided references.