GPT-5.6-Cyber escaped a QEMU/KVM VM three times in twelve hours

On 2026-08-26, Trail of Bits published an experiment in which an AI agent was handed a single objective — break out of a virtual machine — and achieved it three times in roughly twelve hours of unattended work, each time by a different route. The agent was GPT-5.6-Cyber, the cyber-capability model OpenAI gave the research firm preview access to; the target was a QEMU/KVM guest on a Debian 12 host; and the three escapes ran from a freshly disclosed Linux kernel vulnerability to a chain of three zero-days the agent found itself. Nobody outside the lab was harmed — the flag the agent was told to read was a test file on the researcher's own machine — but the finding is aimed at the assumption that a VM is a safe place to run one of these agents. The record itself, with its confidence grade and the note that no real harm was recorded, lives in the Orca AI Incident Archive, next to the evaluation-sandbox entries filed around it that week.

What Trail of Bits actually ran

The write-up is by Artem Dinaburg and sits in Trail of Bits' Patch the Planet work, part of OpenAI's vulnerability-discovery initiative of the same name. OpenAI describes Patch the Planet as a coalition of maintainers, researchers and security providers it convenes to fix critical open-source flaws ahead of disclosure. The agent in this experiment was not a deployed product being tested for a customer: it was preview access handed to a research firm, which is how the write-up describes it.

Dinaburg framed it as a capture-the-flag. The agent had to break out of the guest and read a flag file, beginning with SSH access into the guest and permission to do anything inside it while keeping a research log. Starting from the guest rather than inside the host was deliberate — escape attempts might crash the machine — and the host was configured to hold nothing important, so that an exploit the agent wrote could be audited for cheating rather than treated as an incident. It worked largely unattended for about twelve hours, across what Dinaburg calls "multiple compactions and innumerable subagent invocations": downloading code and papers, backtracking, writing oracles and minimal reproducers, and hunting for an exploit it could reuse. His own role, he says, was mostly rebooting the machine after host kernel hardlocks.

Two details shape how the result should be read. The host ran Debian 12 with CPU mitigations disabled, a configuration the agent noticed and tried to use before abandoning the approach as too unreliable. And the distribution was a stock stable one — the kind most organisations actually deploy — which is the variable the whole experiment ends up turning on.

Escape one: a kernel bug nobody had written an exploit for

Roughly an hour in, the agent had a working exploit for CVE-2026-53359, a host-kernel vulnerability disclosed shortly before the run and known in the write-up as Januscape. In Dinaburg's account there was no public exploit to copy; the agent built one. It did not land cleanly — the host hardlocked instead — and Dinaburg updated the Debian 12 kernel before continuing.

The identifier holds up against public records. NIST's NVD entry for CVE-2026-53359, published 2026-07-04, describes a KVM x86 shadow-paging use-after-free classed as CWE-416 and rated 8.8 on CVSS 3.1 — seven weeks before the experiment, in the virtualisation code the escape targeted. That does not corroborate the escape itself, but it establishes that the label points at a documented kernel flaw rather than one invented for the post.

Escape two: a libslirp bug Debian had already decided to postpone

The second route was not a novel bug at all. Debian 12 shipped libslirp 4.7.0, which carries CVE-2026-9539. The agent combined it with a libslirp fix commit that had been merged upstream without being labelled a security fix — 26be815b86e8d49add8c9a8b320239b9594ff03d — and turned the pair into arbitrary read and write of host memory. "After that, escape is trivial," Dinaburg writes. He then rebuilt a minimal QEMU against the latest upstream QEMU and libslirp and set the agent loose again.

The bookkeeping on this one is checkable, and it is the sharpest part of the finding. Debian's package archive lists libslirp 4.7.0-1 in bookworm, the suite behind Debian 12 — exactly the version the write-up names. Debian's security tracker marks that version vulnerable to CVE-2026-9539 and records the fix as postponed in bookworm, with the note "Minor issue, OOB read"; the fix had reached trixie and unstable. NIST's record, published 2026-06-24, describes an out-of-bounds heap read and integer underflow in libslirp's TCP urgent-data handling before version 4.9.2, allowing a privileged guest to leak gigabytes of host-process heap memory. NVD carries it at 6.5, medium, scored by Star Labs, and still marks it awaiting analysis. The upstream commit the agent chained is titled "ip: Enforce strict aliasing" — a subject line that reads like code hygiene, which is precisely Dinaburg's point about fixes that do not announce themselves.

So the same bug is "minor issue, postponed" in a stable distribution and a stepping stone to host memory read and write in a research lab. Neither party has reconciled that in public, and this piece does not adjudicate it; it reports the two assessments as they stand.

Escape three: three zero-days and one fix that never reached the distribution

With the environment rebuilt from upstream sources, the agent stopped reusing other people's bugs and found its own. The final chain combined three zero-days with one patched vulnerability that was missing from the distribution kernel:

• QEMU VAPIC — an unchecked ROM alias could overlap locked SMRAM, exposing System Management RAM and enabling attacker-controlled SMM execution. Reported; unpatched when the post went out.

• Linux KVM shadow paging — an attacker-modified shadow page stayed out of sync and could be reused. Patched upstream; stable-kernel details were still pending at publication.

• Linux KVM paging64_invlpg() — a stale level-2 role after a guest changed a mapping to 4 KiB produced a writable 2 MiB host-physical mapping, enough to modify the QEMU heap. Fixed by upstream commit 9fd4a4e3a3d9fc0306525d95bf3eca693d311406, which was not in the distribution kernel; that commit is present in mainline, titled "KVM: x86/mmu: Remove FNAME(invlpg) and use FNAME(sync_spte) to update vTLB instead."

• libslirp ICMP — mixed fragment IHLs made reflection copy beyond the reassembled packet, producing thousands of live NetPacket objects that the agent used to locate and hijack a callback. Reported; unpatched when the post went out.

None of the three zero-days carries a CVE identifier in the write-up, and it gives no disclosure timeline, no coordination schedule and no fix dates for them. That is a gap in the record rather than a detail I can fill: the identifiers the piece does cite are the two NVD already carries.

What it found and did not use

The abandoned paths are as informative as the escapes. On the host the agent found a CUPS server; slirp's loopback forwarding exposed a reusable root local certificate, which would have allowed persistent root file overwrite through a file:// printer, until AppArmor stopped it from retrieving the flag. A related CUPS flaw, CVE-2026-34990, had not reached oldstable; NIST's record for it, published 2026-04-03 at 7.8 high, describes a local unprivileged user coercing cupsd into authenticating to an attacker-controlled localhost IPP service with a reusable "Authorization: Local" token.

Other findings went unused. A libslirp IPv6 path over-retained bytes beyond the declared payload, which the agent judged less reliable for host-stream injection. A QEMU panning buffer of 96 bytes for a 1,024-byte render gave a controlled heap overflow, useless because the guest ran with no display. A QEMU queue reset left requests alive, yielding only denial of service and bounded corruption.

Against Firecracker — the minimal device model Trail of Bits recommends — the agent did not escape. It did hardlock the host, through additional Linux kernel flaws that were all patched upstream.

Established, inferred, and not established

Established. The experiment ran on Trail of Bits' own hardware and is documented in a first-person technical write-up with exploit detail. The three routes and their mechanisms are described by the researcher who set the task. The CVE identifiers, the Debian package version, the Debian tracker status and both upstream commits are verifiable in public records, and each was checked against those records for this piece.

Not established. There is no independent replication. The coverage beyond the blog amounts to a CyberInsider summary that draws entirely on the same post and carries no expert comment or third-party verification, and a commentary piece by Edera — an isolation vendor — published 2026-08-27, which reports the findings approvingly, quotes only its own head of security, and discloses that Trail of Bits has audited Edera. Neither is corroboration in the sense that matters: no second lab has reproduced an escape, and no one has audited the transcripts. Neither cited source carries a statement from OpenAI about the result, and I found no published response from the company.

Inferred, not demonstrated. The conclusion — that a general-purpose VM can no longer be assumed to contain a sufficiently capable agent — rests on one model, one host configuration and one researcher's setup. The host ran with CPU mitigations disabled, and some abandoned routes, such as the CUPS chain, were stopped by AppArmor rather than by the hypervisor. Whether the same agent would escape a hardened, monitored production host inside the same twelve hours is not what this experiment measures. Edera's narrower argument is that minimising device emulation "shrinks the target. It doesn't remove it" — a claim about architecture, not a reproduction of the result.

The OrcaRouter blog has covered the adjacent sandbox records — the Codex Heapjack and Overpatch bugs reported in August 2026 and fixed within eight days, and OpenAI's DNS-resolver escape of 20 September 2026 — and none of them involves a hypervisor boundary being crossed this way. Those records concern a tool surface and a network channel; this one concerns the virtualisation stack underneath everything else.

What Trail of Bits says should change

Dinaburg's conclusion is blunt: "you can no longer assume a mere VM will contain a sufficiently advanced AI agent", and such agents should be treated "as an advanced persistent threat". An off-the-shelf VM is not enough, he writes, because there is simply too much attack surface. A distribution with rapid updates becomes a requirement, and older distributions that rely on slow backports should be presumed vulnerable.

The recommendations that follow are operational rather than architectural:

• Use virtualisation with a minimal attack surface — Firecracker, which he calls "obviously a substantially harder target", while noting it is not untouched, since the agent still hardlocked the host through the shared kernel beneath it.

• Apply least privilege, logging and active monitoring to anything an agent is given access to.

• Limit how long an agent operates, and give each use a pristine environment rather than a long-lived one.

• And, in his closing argument, treat security fundamentals — patching cadence, device models, kernel backports — as the binding constraint rather than the model's capability on any given day.

For evaluation work the implication is uncomfortable, and the write-up does not draw it in those words: an eval that measures what a cyber-capable agent can do inside a VM is also measuring the VM. The routes above are three cases where a distribution's backport policy, a commit's subject line and an unpatched device model each decided the outcome. The record does not resolve that question; it documents one twelve-hour run in which the boundary failed three separate ways.