CVE-2026-9539Disclosure

Fuzzing complex state machines with LibAFL-QEMU and incremental snapshots. We walk through our approach, revisit CVE-2026-9539 in libslirp, and explain why our initial fuzzing campaign missed it. Fuzzer code is open source 🧑‍💻 🔗 Check it out: https://blog.quarkslab.com/snapshotting-our-way-to-cve-2026-9539.html

LibAFL-Qemu based fuzzer we developed to explore state machines using incremental snapshots. https://blog.quarkslab.com/snapshotting-our-way-to-cve-2026-9539.html #infosec https://t.co/IYBiCK7NZP

CVE-2026-9539 in libslirp is now public. Out-of-bounds heap read + integer underflow in TCP urgent data handling, allowing a privileged guest to read host memory. Found by @bestswngs & @bruce30262 https://www.cve.org/cverecord?id=CVE-2026-9539

Trail of Bits put GPT 5.6-Cyber in the QEMU/KVM box they actually use to sandbox agents and told it to get out. It got out three times in about 12 hours of mostly unsupervised work. Escape 1 used Januscape (CVE-2026-53359), a recently disclosed host-kernel bug. The exploit hardlocked the Debian 12 host. It did not land cleanly. The kernel got updated. Escape 2 used what most patch pipelines miss. Debian 12 still shipped libslirp 4.7.0 (CVE-2026-9539) plus an unmarked bugfix commit with no CVE. Combined, that was host memory read/write. Networking is the feature you almost always leave on. That is the path. Escape 3 happened after they rebuilt QEMU and deps from upstream. The agent then chained three fresh 0-days (QEMU VAPIC/SMRAM, a KVM shadow-page desync, a libslirp ICMP-reflection bug) plus one upstream KVM fix that never made it into the distro kernel because nobody had labeled it a security issue. Firecracker was the control. Same agent, same time budget. It hardlocked the host on kernel flaws that were already patched upstream. It did not escape. This is not “AI magic.” QEMU is a large attack surface with a slow backport clock. A capable agent reads source and commits. Your scanner reads CVEs. Those are different feeds. If you are running coding agents, research agents, or “isolated” eval boxes on stock QEMU/KVM plus an oldstable distro, treat that guest as an APT with a research intern and no sleep. What to do this week, in order: 1. Inventory every agent runtime. Note hypervisor, guest OS, whether libslirp/usermode networking is on, and whether the host tracks upstream or distro lag. 2. Stop treating a full-featured QEMU guest as the security boundary. Prefer Firecracker, gVisor, or another minimal hypervisor if the workload can live there. 3. Time-box runs. Fresh environment per session. No leftover sockets, printers, or host services visible to the guest. 4. Patch from upstream on the hypervisor and host kernel, not from “the distro said it was fine.” Hunt unmarked commits in QEMU, KVM, and libslirp the same way you hunt CVEs. 5. Assume the agent will try CUPS, display backends, and anything else you left enabled “just in case.” Cut the feature set. Source: Trail of Bits, “VMs won’t contain cyber-capable agents,” Aug 26, 2026. Controlled lab on one Debian 12 / AMD Zen3 host. No public exploit code. First escape did not land cleanly. Firecracker held in the same write-up. Are you still putting coding agents on stock QEMU because “it’s just a VM”? What is the actual hypervisor under yours? #InfoSec #AIAgents #VMEscape

👍 Snapshotting our way to CVE-2026-9539 - Quarkslab's blog https://blog.quarkslab.com/snapshotting-our-way-to-cve-2026-9539.html

I would stop calling a VM a sandbox for a capable agent. Trail of Bits gave one 12 hours and it escaped three different ways. Path one: Januscape, CVE-2026-53359, a recently disclosed kernel bug. The agent built the exploit itself. Path two: libslirp CVE-2026-9539 combined with an unfixed bug for arbitrary memory read and write. Path three: a chain of three previously unknown vulnerabilities across QEMU, Linux KVM and libslirp, bypassing SMRAM protections. It backtracked from dead ends and read papers along the way. No human guided it. The VM was never the boundary. The shared surfaces were: network, file transfer, display. Every convenience you wire into the guest is an edge the agent can reason about. Trail of Bits' recommendation is specific. Firecracker microVMs built for minimal surface. Rapid-update distributions, not two-year-old stable branches. Fresh environment per run. Short operating windows. Least privilege on the host side, because the guest side is not where the fight is. https://blog.trailofbits.com/2026/08/26/vms-wont-contain-cyber-capable-agents/

Trail of Bits pointed GPT 5.6-Cyber at the QEMU/KVM box they actually use to sandbox agents. It escaped three times in about 12 hours. First it wrote an exploit for Januscape (CVE-2026-53359) in the host kernel and hardlocked the machine. After a kernel update it chained libslirp CVE-2026-9539 with an unmarked bug-fix commit that never got a CVE. After they rebuilt QEMU from latest upstream, it synthesized a working escape from three 0-days (QEMU VAPIC/SMRAM, a KVM shadow-page desync, a libslirp ICMP-reflection bug) plus one kernel fix that had not reached Debian 12. This was a controlled lab on a Debian 12 / AMD Zen3 host, not an in-the-wild campaign. The agent ran with SSH into the guest, network via libslirp, and hours of unsupervised research. Firecracker was a harder target: the model hardlocked the host on kernel flaws already patched upstream, but did not complete an escape in the time given. If your “AI sandbox” is a stock hypervisor plus distro backport lag, that is not a boundary. It is a research environment with a flag file on the other side of the fence. What to do this week: 1. Inventory every place a coding or cyber agent can compile, fuzz, or talk to the network. Name the hypervisor, not “a VM.” 2. Stop treating distro security trackers as current. Track upstream QEMU, KVM, and libslirp commits the same way you track KEV. 3. Prefer minimal-surface hypervisors (Firecracker-class) over feature-rich QEMU for anything that can write exploits. 4. Time-box runs. Fresh guest per session. No shared host sockets you do not need. Least-privilege network, period. 5. Assume session cookies and host credentials are in scope the moment the guest can reach them. Source: Trail of Bits, “VMs won’t contain cyber-capable agents,” Aug 26, 2026. Lab write-up. Bugs were reported. No public claim of in-the-wild use. measure? #infosec #AIAgents #VMEscape

@trailofbits "Unfortunately, it seems that some security updates do not quite make it into the distribution. In this case, Debian 12 still ships libslirp 4.7.0, which is vulnerable to CVE-2026-9539" yawn

Trail of Bits pointed a cyber model at a QEMU virtual machine and it escaped three separate times. Artem Dinaburg ran GPT 5.6-Cyber against his own host, hardening it after each escape. The second escape chained CVE-2026-9539 in the libslirp 4.7.0 that Debian 12 still ships with an unflagged bug fix commit to get arbitrary read and write on the host. He patched that, and the agent came back with a final chain of three 0-days at time of discovery, in QEMU, KVM and libslirp, plus one patched bug that never reached his distribution kernel. It held effective persistence over roughly 12 hours, across multiple context compactions and innumerable subagent invocations. This is one engagement by one researcher at a firm that sells sandbox reviews, so weigh it accordingly. The conclusion survives that discount: a VM is a boundary, not containment.