FreeBSD bhyve CVE-2026-101311

Requires the bhyve virtual machine to be configured with the framebuffer/VNC graphical console (the 'fbuf' device exposing the framebuffer BAR and RFB server) - hosts running headless/serial-only guests are not exposed via this path. The attacker must already have code execution inside the guest (PR:L) and must reach the vulnerable framebuffer BAR MMIO writes. Exploitation is LIMITED by: (1) the need to win a timing race between the framebuffer BAR I/O thread and the RFB rendering thread (AC:H), making reliable code execution difficult versus a simple crash; (2) guest-level privilege being a prerequisite, so this is a guest-to-host escape primitive, not a remote-unauthenticated flaw; and (3) bhyve's Capsicum sandbox, which constrains what a successful host-side code-execution payload can do. Affects FreeBSD 14.4, 14.5, and 15.1 release lines prior to the patched levels.

Signals conflict in direction: the CVSS 3.1 base score of 7.0 (High) is driven by full C:H/I:H/A:H impact and the potential for host code execution (CWE-362, RACE condition), but the exploitability metrics temper this significantly - AV:L means the attacker must already be executing inside a guest VM, AC:H reflects the difficulty of reliably winning the timing race between the framebuffer BAR I/O and the unsynchronized RFB rendering thread, and PR:L requires guest-level privilege. No EPSS score, KEV listing, or POC was provided in the input, and there is no public exploit identified at time of analysis - so there is no evidence of widespread or opportunistic exploitation. SSVC-style reasoning: technical impact is total (host userspace code execution / process crash), but exploitation is NOT automatable (requires a race win against a host component and guest tenancy) and is currently in the 'none observed' exploitation state. Net: this is a genuine priority for operators of MULTI-TENANT bhyve hosts where untrusted guests run with a VNC/framebuffer console, but it is not a mass-exploitation / internet-facing emergency. The Capsicum sandbox around bhyve further caps the blast radius of any successful code execution, which the vendor explicitly notes as a limiting factor.

A malicious or already-compromised guest on a bhyve host that is configured with the VNC/framebuffer (fbuf) device writes arbitrary, oversized width and height values to the framebuffer BAR and races the unsynchronized RFB rendering thread, driving memory corruption in the host-side bhyve process. No public exploit was identified at time of analysis; success requires winning a timing-sensitive race (AC:H) from guest-level access (PR:L). The most reliable outcome is a crash (DoS) of the bhyve process, with potential-but-harder arbitrary code execution in the host userspace context, constrained by bhyve's Capsicum sandbox.