FreeBSD bhyve EUVD-2026-101932

Exploitation requires the attacker to already be running malicious, privileged code inside a bhyve-hosted guest VM that uses the emulated xHCI (USB 3) device model - i.e., a VM configured with the bhyve xhci USB controller. The specific trigger is the guest repeatedly modifying the event ring size and TRB fields in guest memory (which bhyve re-reads on each use without validation or saving), so the attacker must win a concurrent-modification race (AC:H) to corrupt host-side handling. LIMITING FACTORS: no network vector (local to the hypervisor host via a controlled guest, AV:L); requires in-guest privilege (PR:L); requires defeating the timing race, reducing reliability; and bhyve's Capsicum sandbox constrains the host-side impact of any code execution. Not exploitable against hosts whose guests do not expose the xHCI model, and fixed releases validate and save the ring size.

This is a moderate, defense-in-depth priority rather than an urgent fire. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U, C:H/I:H/A:H, base 7.0) tells a consistent story with the description: exploitation is local to the virtualization context (the attacker must already be running privileged code inside a bhyve guest), requires winning a race condition (AC:H), and if successful yields high confidentiality/integrity/availability impact in the host userspace process. All signals point the same direction - no network exposure and real exploitation friction from the race. EPSS is low at 0.18% (7th percentile), there is no CISA KEV listing, and no public exploit was identified, so there is no evidence of active or imminent widespread exploitation; this reads as a hard-to-weaponize memory-safety/race bug rather than a mass-exploitation threat. The scope is marked Unchanged (S:U) and the vendor explicitly notes bhyve's Capsicum sandbox constrains the blast radius even on successful host code execution, which is a meaningful mitigating factor. The main conflict to note: the Tag 'RCE' and the vendor language ('potentially execute arbitrary code') overstate reliability - the realistic and confirmed outcome is a bhyve process crash (guest-triggered host DoS), with arbitrary code execution described only as a possibility and gated by the race and the sandbox.

An attacker who already controls a bhyve guest with privileged (in-guest root/kernel) code manipulates the emulated xHCI USB 3 controller, repeatedly changing the event ring size and TRB fields in guest memory while bhyve re-reads them, racing the host's access. By winning the timing window they corrupt bhyve's handling of the event ring, crashing the host bhyve process (denial of service for that VM) or potentially achieving code execution in the host userspace context, constrained by Capsicum. No public exploit code was identified at time of analysis, and the AC:H race makes reliable exploitation non-trivial.