Oracle VM VirtualBox CVE-2026-71125

Exploitation requires: (1) local logon access to the physical or virtual host infrastructure where Oracle VM VirtualBox 7.2.14 is running - remote network exploitation is not possible given AV:L; (2) human interaction from a person other than the attacker, meaning a legitimate VirtualBox user must be actively using or interacting with VirtualBox at or near the time of the attack (UI:R); and (3) the affected version must be exactly 7.2.14, the only confirmed vulnerable release per the Oracle CPU. No special privileges beyond a local user account are required (PR:N), meaning any standard OS user on the host can attempt the attack. Exploitation is limited by the mandatory UI:R dependency, the local-only attack surface, and the absence of confidentiality impact - this cannot be used for data theft. Fully remote, unauthenticated exploitation is not possible.

The real-world risk of this vulnerability is moderate-to-low despite the 'easily exploitable' descriptor in the Oracle advisory. The CVSS 3.1 base score of 6.1 (Medium) is driven by the high availability impact (A:H), but the local attack vector (AV:L) and mandatory user interaction (UI:R) are significant risk reducers. An attacker must already have a local session on the host and must depend on a separate legitimate user to interact with VirtualBox to trigger the flaw - this two-party dependency substantially complicates real-world exploitation. No EPSS data was provided, and the absence of a KEV listing and public POC further reduces urgency. The integrity impact is limited (I:L), and there is no confidentiality impact (C:N), ruling out data exfiltration scenarios. This is not a cross-VM escape or host-takeover; the blast radius is limited to crashing or disrupting the VirtualBox process. Priority should be higher for multi-user shared VirtualBox infrastructure (e.g., lab environments or shared developer systems) where untrusted local users coexist with VirtualBox operators.

A local user with an unprivileged account on a shared VirtualBox host waits for a legitimate VirtualBox operator to start or interact with a virtual machine. By sending crafted input or triggering a specific operation through shared host resources (e.g., named pipes, shared memory, or device interfaces), the attacker causes the VirtualBox Core component to crash, disrupting all running virtual machines on that host and potentially corrupting a subset of VirtualBox-accessible data. No public exploit code exists at time of analysis, but the low attack complexity (AC:L) suggests an exploit would not be technically demanding once a local foothold is established.