Oracle VM VirtualBox CVE-2026-101599

Exploitation requires a local logon (AV:L) to the host infrastructure where VirtualBox runs - in practice a low-privileged account inside a guest VM (PR:L) - against VirtualBox 7.2.20, and critically depends on interaction from a person other than the attacker (UI:R), such as an operator or administrator performing an action on the VM. High attack complexity (AC:H) means additional non-trivial conditions must be met for reliable exploitation. These limiting factors - local-only vector, required second-party interaction, and high complexity - substantially constrain realistic exploitation despite the full-takeover impact; there is no remote or unauthenticated path.

Oracle rates this 7.5 (High) with vector CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H, which is a textbook Oracle VirtualBox guest-escape profile: the attack is local (AV:L - attacker needs a logon to the infrastructure where VirtualBox runs, typically a guest VM), is hard to pull off (AC:H), needs low privileges (PR:L), and requires interaction from a different person (UI:R), but yields full confidentiality/integrity/availability compromise with a scope change (S:C) impacting the host beyond the VM. Real-world risk is tempered by the combination of AC:H + UI:R + AV:L: this is not a remotely weaponizable issue and demands a multi-condition local foothold plus a victim action, so it is a patch-in-normal-cycle item rather than an emergency. No EPSS score, no KEV listing, and no public POC were provided, all of which point to low near-term mass-exploitation likelihood; EPSS and exploitation-maturity data are simply absent from the input and should be checked against NVD/FIRST before final prioritization. Note the 'Information Disclosure' tag understates the issue - the description and CVSS (C:H/I:H/A:H, takeover) describe full compromise, not mere disclosure.

An attacker with a low-privileged logon inside a guest VM triggers a difficult-to-exploit flaw in the VirtualBox Core component, but only succeeds when another user (e.g., an administrator operating the VM) performs a required interaction. Successful exploitation escapes the guest and compromises the VirtualBox host with full confidentiality, integrity, and availability impact (scope change). No public exploit code was identified at time of analysis.