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

Octane Security has discovered a heap overflow vulnerability in Oracle VM VirtualBox's streamOptimized VMDK parser, assigned CVE-2026-60161, which allows a malicious virtual appliance to write up to 65,536 attacker-controlled bytes beyond a 66,048-byte heap allocation. The vulnerability, introduced nearly 16 years ago in a 2010 refactor, affects VirtualBox 6.1.50 and 7.2.12 and could contribute to reliable code execution when paired with other exploits. Oracle, which reported record FY 2026 sales of $67.4 billion, has assigned the CVE, and VirtualBox is used by IBM, Google, Uber, Airbnb, and security firms like Rohde & Schwarz Cybersecurity and Secunet.

Three months ago, we announced Octane’s first CVE https://www.octane.security/post/octane-finds-vulnerabilities-in-all-major-internet-browsers 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 https://nvd.nist.gov/vuln/detail/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. Oracle is one of the world’s largest enterprise software companies, generating a record $67.4 billion in FY 2026 sales https://investor.oracle.com/investor-news/news-details/2026/Oracle-Announces-Record-Q4-and-FY-2026-Results-Driven-by-Cloud-Infrastructure--Cloud-Applications/default.aspx . VirtualBox https://www.virtualbox.org/ 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 https://www.rohde-schwarz.com/us/products/cybersecurity/secure-web-browser/rs-browser-in-the-box-workstation 63493-543616.html , 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 https://github.com/VirtualBox/virtualbox/commit/40634a6c89198e4ce08558ab8943b6e45ecb4798 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 https://download.virtualbox.org/virtualbox/3.2.10/ , 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 https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/remote-code-execution/ . Modern systems use defenses such as Address Space Layout Randomization https://documentation.ubuntu.com/security/security-features/process-memory/aslr/ , 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: php 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: php 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: php 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: python 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 https://nvd.nist.gov/vuln/detail/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 https://blogs.oracle.com/security/accelerating-vulnerability-detection-and-response-at-oracle 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 https://www.anthropic.com/research/glasswing-initial-update 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 https://www.octane.security/schedule-demo . Subscribe to our newsletter