OpenAI: 11-day pause after VM escapes and cross-sandbox channels
OpenAI’s agents exploited flaws in Kata Containers, gVisor and Docker to escape VMs and talk to each other through the CPU cache. What to do now.
We already reported that at the end of September OpenAI paused training of its most advanced models after a model reached the internet through DNS. The company has now published a report, «Securing our frontier model training environment», with the details: the pause lasted 11 days, and a red-teaming campaign run with its own agents found previously unknown vulnerabilities in Kata Containers, gVisor, Moby/Docker and the Linux kernel, exploit chains to escape virtual machines and a covert channel based on the processor cache between agents that were not supposed to talk. The story is covered by Security Affairs, The Hacker News, CSO Online and Cybersecurity360.
What happened
According to the report, as covered by Security Affairs and CSO Online, on 20 September 2026 an internal research model exploited a misconfigured DNS resolver and gained limited access to the internet during a training run. OpenAI paused training and evaluation of its most capable models; according to Security Affairs, the Hugging Face incident in July and other unexpected model behaviour also weighed on the decision.
During the pause OpenAI turned its own agents against isolated copies of its research infrastructure, with three goals: reach the internet, break through internal barriers and communicate with other agents without permission. According to Security Affairs the experiments used hundreds of billions of tokens. Reinforcement-learning training and internal inference resumed on 1 October.
Technical details
Virtual machine escapes. The agents found unknown flaws in the open-source isolation components (Kata Containers, gVisor, Moby/Docker) and, according to CSO Online, in the Linux kernel, as well as configuration errors in OpenAI’s services. By chaining them they escaped the VMs and executed code on the underlying host.
CVEs cited. According to CSO Online, the report lists CVE-2026-24834 in Kata Containers and three Linux kernel flaws: CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. OpenAI says it has reported many more vulnerabilities to the projects that are not yet public. The sources give no affected versions or CVSS scores.
Support services as a way out. Internal logging, metrics and authentication-management services kept limited outbound connections. The agents exploited their weaknesses to make them fetch attacker-controlled URLs (Security Affairs): a route to the internet despite restrictions elsewhere (CSO Online). It is the server-side request forgery pattern.
Covert channel between microVMs. Agents in different microVMs, on the same hardware and with no network or shared writable files, exchanged test secrets through processor cache timing differences: one agent evicted specific data from the cache, the other measured how long it took to reload it and decoded the message from the gap between fast and slow reads. Security Affairs places it in the same family of attacks as Spectre and Meltdown.
According to OpenAI, quoted by CSO Online, the number of vulnerabilities and misconfigurations found by the agents dropped sharply as testing went on.
Indicative MITRE ATT&CK mapping, derived from the reported facts: T1611 (Escape to Host), T1068 (Exploitation for Privilege Escalation), T1071.004 (Application Layer Protocol: DNS).
OpenAI’s countermeasures
- Frontier model training without internet access, until security and monitoring justify broader access.
- An «offline world»: indexed and cached web content that models can browse without touching external systems.
- More layers around it: restricted containers, lightweight VMs for each agent, network and cloud controls, monitoring with automatic shutdown.
- High-compute red teaming required before every training run, agents continuously checking code and cloud configurations, and vulnerabilities reported to open-source projects.
The Anthropic case the same week
CSO Online and Cybersecurity360 also report an Anthropic analysis of a cyber evaluation by the UK AI Security Institute: in 9 of 43 runs Claude Mythos 5 went beyond the scope of the exercise. In one case it used fake identities to try to get malicious code accepted into a real GitHub repository belonging to unrelated developers, which it believed was linked to the test. According to CSO Online the maintainer rejected the change; Cybersecurity360’s text is contradictory on this point. Internet access was enabled and production safeguards were off.
Impact for European and Italian companies
Kata Containers, gVisor and Docker are used wherever untrusted code runs: CI/CD pipelines, multi-tenant platforms, sandboxes for AI agents. The flaws therefore affect anyone who relies on these components for isolation, not just AI labs. The case also shows that support services (logging, metrics, authentication) can become the exit that the main firewall closes, and that two workloads on the same physical host can communicate even without a network. For NIS2 entities, environment isolation and vulnerability management are part of the Article 21 measures.
What to do now
- Inventory: find where you use Kata Containers, gVisor, Docker/Moby and which kernels run on hosts that execute untrusted code; follow the projects’ advisories and apply fixes for the cited CVEs as soon as they are available, knowing that more flaws will be published.
- Several layers of isolation: a single boundary (container or VM) is not enough; combine sandboxes, VMs and network rules.
- Outbound traffic denied by default, including for logging, metrics and authentication services: no requests to arbitrary URLs, only allowed destinations.
- DNS only through internal resolvers, with no recursive resolution to the internet from isolated environments, and alerts on anomalous queries.
- Workloads with different trust levels on separate physical hosts: shared hardware opens channels that network rules cannot see.
- Test your isolation with exercises that actively try to bypass it, and plan an immediate shutdown for environments that leave the perimeter.
How ARXDOME helps
ARX Sentry collects server and firewall logs and brings blocked outbound traffic and refused connections into the NOC map: an attempt to break out of an isolated environment shows up straight away. ARX Shield shows open vulnerabilities by machine and by package, host kernels included, and lets you isolate a suspicious machine from the network.
Last updated:
