CVE-2024-21115

What it actually does

Local low-privileged process on the host can escape its sandbox and obtain full control of the VirtualBox process and its guest VMs due to an unsandboxed code path in the Core component.

Why it matters to the business

Attackers who already have a foothold on a virtualization host can seize control of all running virtual machines, exposing every workload on that host and any data they contain.

How an attack unfolds

An attacker logs into the host with a low-privileged account, executes a crafted program that triggers the flaw in VirtualBox's Core component, escalates privileges within the VirtualBox process, and from there takes over the hypervisor and all guests.

How to fix it

Upgrade every Oracle VM VirtualBox installation to version 7.0.16 or later. Remove or restrict local accounts that do not need access to the host.

How to confirm the fix worked

Run 'VBoxManage --version' on each host and confirm the reported version is 7.0.16 or newer; re-scan hosts with vulnerability management tools after patching.

Typical attack path

1. Obtain low-privileged local shell on the virtualization host
2. Execute malicious binary that interacts with VirtualBox Core
3. Trigger the vulnerability to break out of the process sandbox
4. Hijack the VirtualBox process and all attached VMs

How to detect it

Review host authentication logs for unexpected low-privileged sessions, inspect VirtualBox process trees for anomalous child processes, and look for post-exploitation artifacts such as new scheduled tasks or unexpected network connections originating from the VirtualBox binary.

What your security team should do

• Immediately schedule upgrade of all VirtualBox hosts to 7.0.16
• Limit local logons on virtualization hosts to the minimum necessary accounts
• Monitor host logs for unexpected VirtualBox process behavior until patches are applied