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.
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.
.png)
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.
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
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.
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.
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.
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.
- CVE: CVE-2026-60161
- Product: Oracle VM VirtualBox
- Component: Virtual Disk library, VMDK backend
- Function:
vmdkFileInflateSync() - Weakness: CWE-787, Out-of-bounds Write
- CVSS 3.1: 6.1 Medium
- Vector:
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H - Reproduced versions: VirtualBox 6.1.50 and 7.2.12
- Demonstrated impact: Attacker-controlled heap corruption and reproducible process termination
- Potential impact: Could contribute to reliable code execution when paired with an appropriate disclosure primitive or other mitigation bypass
How this fits into an RCE chain
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).
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.
A common exploit chain therefore combines 2 primitives:
- A memory disclosure primitive reveals data or addresses from the target process.
- A memory corruption primitive uses that knowledge to overwrite something valuable.
The first answers: Where should the attacker go?
The second answers: What can the attacker change once there?
We did not develop a reliable code execution exploit for VirtualBox or identify an equivalent disclosure primitive inside the same VirtualBox process.
How the overflow happens
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.
VirtualBox allocates a fixed buffer to hold one compressed grain:
pExtent->cbCompGrain =
RT_ALIGN_Z(VMDK_SECTOR2BYTE(pExtent->cSectorsPerGrain)
+ 8 + sizeof(VMDKMARKER), 512);
pExtent->pvCompGrain = RTMemAlloc(pExtent->cbCompGrain);
For the default 64 KiB grain used in our proof of concept, the allocation is 66,048 bytes.
Later, vmdkFileInflateSync() reads the compressed size from the attacker-controlled marker:
cbCompSize = RT_LE2H_U32(pMarker->cbSize);
if (cbCompSize >= 2 * cbToRead)
return VERR_VD_VMDK_INVALID_FORMAT;
The guard compares the compressed size against twice the uncompressed grain size, not against the capacity of the destination buffer.
As a result, a value can pass the format check even when the resulting read cannot fit inside pvCompGrain.
VirtualBox then reads the aligned amount directly into that buffer:
rc = vdIfIoIntFileReadSync(
pImage->pIfIo,
pExtent->pFile->pStorage,
uOffset + RT_UOFFSETOF(VMDKMARKER, uType),
(uint8_t *)pExtent->pvCompGrain
+ RT_UOFFSETOF(VMDKMARKER, uType),
RT_ALIGN_Z(
cbCompSize + RT_UOFFSETOF(VMDKMARKER, uType),
512
) - RT_UOFFSETOF(VMDKMARKER, uType)
);
Under the demonstrated configuration, the validation permits a read that reaches exactly 65,536 bytes beyond the allocation.
One full grain crosses the heap boundary.
The overflow occurs during the file read, before decompression. The attacker does not need to construct valid compressed data. VirtualBox has already written the file’s bytes into memory it does not own.
From AI finding to proven memory corruption
Octane’s AI surfaced the underlying boundary failure in VirtualBox’s streamOptimized VMDK parser. The parser trusted an attacker-controlled compressed size to determine how many bytes it would read, but validated that value against the uncompressed grain size rather than the capacity of the destination buffer. That was the novel finding.
But a promising output is not yet a proven vulnerability.
An Octane security researcher had to take the finding further. They constructed a malicious VMDK, packaged it into a virtual appliance and expanded the trigger to demonstrate a controlled overwrite reaching exactly 65,536 bytes beyond the allocated heap buffer.
The researcher then validated the primitive through three separate execution paths.
First, importing the malicious appliance caused the VirtualBox service handling the operation to terminate:
Interpreting /work/evil.ova...
VBoxManage: error: Appliance import failed
VBoxManage: error: Code NS_ERROR_ABORT
Next, the researcher extracted the same virtual disk and passed it directly through VirtualBox’s conversion path. This exposed the underlying allocator failure:
double free or corruption (!prev)
Finally, they ran the VirtualBox disk library shipped by Oracle under Valgrind. Valgrind traced an invalid pread64() destination through VDRead and located it immediately after the 66,048-byte allocation created during VDOpen.
Syscall param pread64(buf) points to unaddressable byte(s)
Address 0x84a5dd0 is 0 bytes after a block
of size 66,048 alloc'd
Valgrind later reported a heap block size mismatch, confirming that the write had crossed the allocation and corrupted neighboring allocator metadata.
On Linux, glibc detects the damaged heap and aborts the process.
Octane’s AI found the boundary failure. Our researcher then converted it into a controlled, measured and reproducible memory corruption primitive.
This partnership between human and AI is a highly synergistic one. AI can explore more code and surface attack paths that are difficult to reason through manually. Security researchers can then instrument the target, refine the trigger and produce the evidence required for disclosure and remediation
Two CVEs = two sides of the same equation
CVE-2026-60161 follows Octane’s discovery of CVE-2026-5888, a heap information disclosure vulnerability in Chromium’s WebCodecs implementation.
The Chromium vulnerability allowed a malicious page to receive bytes from renderer memory that JavaScript was never supposed to access. The VirtualBox vulnerability lets a malicious disk image write attacker-controlled bytes beyond an allocated heap buffer.
Octane has now independently found both classes of primitive that often form a reliable RCE chain:
- A memory disclosure primitive.
- An attacker-controlled memory corruption primitive.
The vulnerabilities affect separate products and cannot be chained as discovered. Their significance is cumulative: Octane has independently found two classes of primitive commonly combined in reliable RCE chains.
One exposes memory, the other corrupts it. Together, they show that Octane can solve for both sides of the exploit equation in mature, heavily reviewed low-level systems.
A frontier model is only an engine
Months ago, Oracle publicly confirmed it has access to Anthropic’s Claude Mythos Preview, the cyber model at the heart of Project Glasswing. The company also says it is applying frontier models across its own software, services and the open-source components it builds and uses.
Clearly, Oracle is investing heavily in AI-native cybersecurity. But Octane still found the bug.
This demonstrates that even access to the strongest frontier cyber models does not remove the need for specialized systems and skilled human researchers.
Anthropic’s own Project Glasswing reporting points in the same direction. Partners have used Mythos to surface thousands of serious vulnerability candidates, but those findings still require human assessment, responsible disclosure, and remediation.
Raw model capability is only one part of the stack.
A security system must decide where to look, construct the right context, direct compute toward promising attack surfaces, distinguish a plausible theory from a real boundary failure and prove the result against shipped software. Then a researcher must reproduce the failure, establish its impact, and give the maintainer enough evidence to fix it.
The frontier model is an engine. It is not your entire security system.
Our two CVEs are the primitives serious exploit chains are built from. They show Octane moving deeper into mature codebases, low-level systems, and attack surfaces that have already been studied by some of the best security teams in the world… and still finding bugs.
Your codebase has already been audited. Great. Now give Octane the target everyone else thinks is clean. Reach out to speak with our team today.
Subscribe to our newsletter
