{"slug": "oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161", "title": "Oracle VM VirtualBox Bug Discovered by AI: CVE-2026-60161", "summary": "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.", "body_md": "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.\n\nOctane 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.\n\nOracle 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.\n\nIBM, 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.\n\n**The vulnerability at a glance**\n\nVirtualBox 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.\n\nThis particular vulnerability appears to have been introduced into VirtualBox ** almost 16 years ago**. Source history traces the vulnerable read path to an\n\n[October 4, 2010 refactor](https://github.com/VirtualBox/virtualbox/commit/40634a6c89198e4ce08558ab8943b6e45ecb4798)of VirtualBox’s VMDK compression and decompression code.\n\nThe change entered the VirtualBox source tree as revision `r66363`\n\n. VirtualBox 3.2.10, build `66523`\n\n, 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.\n\nOctane found a memory corruption primitive that survived nearly 16 years in mature, publicly available code. That’s the definition of a hard public target.\n\n**CVE:** CVE-2026-60161**Product:** Oracle VM VirtualBox**Component:** Virtual Disk library, VMDK backend**Function:**`vmdkFileInflateSync()`\n\n****** 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`\n\n****** 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\n\n**How this fits into an RCE chain**\n\nA 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/).\n\nModern 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.\n\nA common exploit chain therefore combines 2 primitives:\n\n- A memory disclosure primitive reveals data or addresses from the target process.\n- A memory corruption primitive uses that knowledge to overwrite something valuable.\n\nThe first answers: *Where should the attacker go?*\n\nThe second answers: *What can the attacker change once there?*\n\nWe did not develop a reliable code execution exploit for VirtualBox or identify an equivalent disclosure primitive inside the same VirtualBox process.\n\n**How the overflow happens**\n\nVirtualBox divides a `streamOptimized`\n\nVMDK disk into compressed grains. Each grain includes a marker containing its compressed size. That size comes from the image itself.\n\nVirtualBox allocates a fixed buffer to hold one compressed grain:\n\n``` php\npExtent->cbCompGrain =\n    RT_ALIGN_Z(VMDK_SECTOR2BYTE(pExtent->cSectorsPerGrain)\n               + 8 + sizeof(VMDKMARKER), 512);\n\npExtent->pvCompGrain = RTMemAlloc(pExtent->cbCompGrain);\n```\n\nFor the default 64 KiB grain used in our proof of concept, the allocation is **66,048 bytes**.\n\nLater, `vmdkFileInflateSync()`\n\nreads the compressed size from the attacker-controlled marker:\n\n``` php\ncbCompSize = RT_LE2H_U32(pMarker->cbSize);\n\nif (cbCompSize >= 2 * cbToRead)\n    return VERR_VD_VMDK_INVALID_FORMAT;\n```\n\nThe guard compares the compressed size against twice the uncompressed grain size, not against the capacity of the destination buffer.\n\nAs a result, a value can pass the format check even when the resulting read cannot fit inside `pvCompGrain`\n\n.\n\nVirtualBox then reads the aligned amount directly into that buffer:\n\n``` php\nrc = vdIfIoIntFileReadSync(\n    pImage->pIfIo,\n    pExtent->pFile->pStorage,\n    uOffset + RT_UOFFSETOF(VMDKMARKER, uType),\n    (uint8_t *)pExtent->pvCompGrain\n        + RT_UOFFSETOF(VMDKMARKER, uType),\n    RT_ALIGN_Z(\n        cbCompSize + RT_UOFFSETOF(VMDKMARKER, uType),\n        512\n    ) - RT_UOFFSETOF(VMDKMARKER, uType)\n);\n```\n\nUnder the demonstrated configuration, the validation permits a read that reaches exactly 65,536 bytes beyond the allocation.\n\nOne full grain crosses the heap boundary.\n\nThe 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.\n\n**From AI finding to proven memory corruption**\n\nOctane’s AI surfaced the underlying boundary failure in VirtualBox’s `streamOptimized`\n\nVMDK 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.\n\nBut a promising output is not yet a proven vulnerability.\n\nAn 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.\n\nThe researcher then validated the primitive through three separate execution paths.\n\nFirst, importing the malicious appliance caused the VirtualBox service handling the operation to terminate:\n\n``` python\nInterpreting /work/evil.ova...\nVBoxManage: error: Appliance import failed\nVBoxManage: error: Code NS_ERROR_ABORT\n```\n\nNext, the researcher extracted the same virtual disk and passed it directly through VirtualBox’s conversion path. This exposed the underlying allocator failure:\n\n```\ndouble free or corruption (!prev)\n```\n\nFinally, they ran the VirtualBox disk library shipped by Oracle under Valgrind. Valgrind traced an invalid `pread64()`\n\ndestination through `VDRead`\n\nand located it immediately after the 66,048-byte allocation created during `VDOpen`\n\n.\n\n```\nSyscall param pread64(buf) points to unaddressable byte(s)\n\nAddress 0x84a5dd0 is 0 bytes after a block\nof size 66,048 alloc'd\n```\n\nValgrind later reported a heap block size mismatch, confirming that the write had crossed the allocation and corrupted neighboring allocator metadata.\n\nOn Linux, glibc detects the damaged heap and aborts the process.\n\nOctane’s AI found the boundary failure. Our researcher then converted it into a controlled, measured and reproducible memory corruption primitive.\n\nThis 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\n\n**Two CVEs = two sides of the same equation**\n\nCVE-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.\n\nThe 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.\n\nOctane has now independently found both classes of primitive that often form a reliable RCE chain:\n\n- A memory disclosure primitive.\n- An attacker-controlled memory corruption primitive.\n\nThe 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.\n\nOne 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.\n\n**A frontier model is only an engine**\n\nMonths 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.\n\nClearly, Oracle is investing heavily in AI-native cybersecurity. But Octane still found the bug.\n\nThis demonstrates that even access to the strongest frontier cyber models does not remove the need for specialized systems and skilled human researchers.\n\n[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.\n\nRaw model capability is only one part of the stack.\n\nA 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.\n\n*The frontier model is an engine**. It is not your entire security system.*\n\nOur 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.\n\nYour 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).\n\nSubscribe to our newsletter", "url": "https://wpnews.pro/news/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161", "canonical_source": "https://octane.security/post/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161", "published_at": "2026-07-31 17:08:23+00:00", "updated_at": "2026-07-31 17:22:49.631527+00:00", "lang": "en", "topics": ["ai-research", "ai-tools"], "entities": ["Octane Security", "Oracle", "VirtualBox", "CVE-2026-60161", "IBM", "Google", "Uber", "Airbnb"], "alternates": {"html": "https://wpnews.pro/news/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161", "markdown": "https://wpnews.pro/news/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161.md", "text": "https://wpnews.pro/news/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161.txt", "jsonld": "https://wpnews.pro/news/oracle-vm-virtualbox-bug-discovered-by-ai-cve-2026-60161.jsonld"}}