Oracle VM VirtualBox Bug Discovered by AI: CVE-2026-60161

Log in

Home›Blog›Oracle VM VirtualBox Bug Discovered by AI: CVE-2026-60161<br>Oracle VM VirtualBox Bug Discovered by AI: CVE-2026-60161<br>Security<br>Giovanni Vignone<br>CEO Octane

Jesse Leclere<br>Growth and Demand Generation Lead

Published:

July 23, 2026

Share this article

Table of contents<br>LINK

Subscribe to our newsletter

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Three months ago, we announced Octane’s first CVE for a heap information disclosure vulnerability in Chromium. Today, following our disclosure of a memory corruption primitive in VirtualBox, we’re proud to announce that Oracle has assigned CVE-2026-60161 to a memory corruption vulnerability Octane discovered in VirtualBox.<br>Octane found a heap overflow in VirtualBox’s streamOptimized VMDK parser whose length and contents are controlled by the malicious image. A malicious virtual appliance can cause VirtualBox to write up to 65,536 attacker-controlled bytes beyond a 66,048-byte heap allocation.

Figure: A malicious VMDK can force VirtualBox to write 65,536 attacker-controlled bytes beyond a 66,048-byte heap buffer, corrupting adjacent heap memory.Oracle is one of the world’s largest enterprise software companies, generating a record $67.4 billion in FY 2026 sales. VirtualBox is the world’s most popular open-source, cross-platform virtualization product. It is used for software development, testing, cloud deployment, legacy application support and secure remote work.<br>IBM, Google, Uber, Airbnb, and many other public companies use VirtualBox, while the software also plays a key role in multiple specialist security products. Rohde & Schwarz Cybersecurity uses it as the foundation of its Browser in the Box, and Secunet, a major German cybersecurity contractor, embeds VirtualBox in secure virtualized workstations designed to access highly classified information for clients including the German federal government and NATO.

The vulnerability at a glance<br>VirtualBox is mature, open-source infrastructure used in development, testing and security-sensitive workstations. Its code has been available to Oracle engineers and independent researchers for years.<br>This particular vulnerability appears to have been introduced into VirtualBox almost 16 years ago . Source history traces the vulnerable read path to an October 4, 2010 refactor of VirtualBox’s VMDK compression and decompression code.<br>The change entered the VirtualBox source tree as revision r66363. VirtualBox 3.2.10, build 66523, was released four days later on October 8, 2010, making it the first release to contain the vulnerable path.<br>Octane found a memory corruption primitive that survived nearly 16 years in mature, publicly available code. That’s the definition of a hard public target.<br>CVE: CVE-2026-60161<br>Product: Oracle VM VirtualBox<br>Component: Virtual Disk library, VMDK backend<br>Function: vmdkFileInflateSync() ‍<br>Weakness: CWE-787, Out-of-bounds Write‍<br>CVSS 3.1: 6.1 Medium‍<br>Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H ‍<br>Reproduced versions: VirtualBox 6.1.50 and 7.2.12‍<br>Demonstrated impact: Attacker-controlled heap corruption and reproducible process termination‍<br>Potential impact: Could contribute to reliable code execution when paired with an appropriate disclosure primitive or other mitigation bypass<br>How this fits into an RCE chain<br>A memory corruption vulnerability gives an attacker a way to alter a process beyond the boundaries intended by its developers. That does not automatically produce remote code execution (RCE).<br>Modern systems use defenses such as Address Space Layout Randomization, or ASLR. ASLR changes where important data and executable code live whenever a process starts. An attacker may control the bytes being written without knowing the useful address to target.<br>A common exploit chain therefore combines 2 primitives:<br>A memory disclosure primitive reveals data or addresses from the target process.<br>A memory corruption primitive uses that knowledge to overwrite something valuable.<br>The first answers: Where should the attacker go?<br>The second answers: What can the attacker change once there?<br>We did not develop a reliable code execution exploit for VirtualBox or identify an equivalent disclosure primitive inside the same VirtualBox process.<br>How the overflow happens<br>VirtualBox divides a streamOptimized VMDK disk into compressed grains. Each grain includes a marker containing its compressed size. That size comes from the image itself.<br>VirtualBox allocates a fixed buffer to hold one compressed grain:<br>pExtent->cbCompGrain =<br>RT_ALIGN_Z(VMDK_SECTOR2BYTE(pExtent->cSectorsPerGrain)<br>+ 8 + sizeof(VMDKMARKER), 512);

pExtent->pvCompGrain = RTMemAlloc(pExtent->cbCompGrain);‍<br>For the default 64 KiB grain used in our proof of concept, the allocation is 66,048 bytes .<br>Later, vmdkFileInflateSync() reads the compressed size from the attacker-controlled marker:<br>cbCompSize =...