Docker Security Vulnerabilities in AI Workload Containers
AI agents write code at runtime, breaking the security model Docker was built on.
Docker's shared-kernel container was never built to run code the workload writes for itself, and that's exactly what AI agents do now. This piece walks through the vulnerability classes that matter most for AI workloads: container escape, runtime bugs in runc, privilege escalation, supply chain poisoning, plain old misconfiguration. Then it gets to the harder question, the one most security teams haven't fully worked through yet: what happens when the thing running inside the container is code the container itself just wroteseconds ago, off a prompt nobody vetted.
Adoption is moving faster than the hardening work needed to keep up with it. The AI agent market is set to grow from $7.84 billion in 2025 to $52.62 billion by 2030, a 46.3% compound annual growth rate. Gartner expects 33% of enterprise applications to include agentic AI by 2028, up from less than 1% in 2024, and pilot programs nearly doubled in a single quarter, from 37% to 65% of surveyed enterprises. Full production deployment, though, sits at just 11%. So where does the missing 89% go? Probably nowhere dramatic. It piles up quietly between pilot and production, since a pilot rarely gets the scrutiny a production system demands, and by the time anyone looks closely, the bad habits are already baked in.
In a normal deployment, a developer wrote the code, a colleague looked it over, and nothing changed once the image got built. An AI agent breaks that at every step. It writes code at runtime, often shaped by inputs it doesn't control: a user's prompt, a tool's output, a document pulled from somewhere it shouldn't have gone. It calls tools, writes files, and sends network requests on its own, and each of those is a fresh place for an attacker to push on. Research from 2025 found that 45% of AI-generated code fails security tests. The container was built around the assumption that whatever runs inside it already passed through a human's judgment once. Take that assumption away and the container stops isolating a workload in the way it once did. It becomes the last thing standing between production infrastructure and code that is, by the numbers, close to a coin flip on whether it's even safe to run.
Container escape via shared kernel: the structural flaw every other vulnerability class exploits
Every vulnerability class in this piece leans on one architectural fact: Docker containers share the host's kernel. Isolation comes from Linux namespaces and cgroups, process-level boundaries, not a separate kernel for each workload. So what happens when that boundary fails?
A successful container escape means an attacker's process breaks out of its namespace and lands, with whatever privileges it grabbed on the way out, directly on the host. From there, everything else on that host is in reach: sibling containers, mounted volumes, cloud instance metadata, credentials sitting in environment variables or config files nobody thought to encrypt. In a multi-tenant AI deployment, where one host might run dozens of agent workloads for different customers or different tasks, this isn't a single-agent compromise. It's a blast radius covering every workload on the box.
MITRE ATT&CK classifies container escape as technique T1611, a documented, tracked pattern that security teams watch for because it keeps happening. Here's the part that should worry anyone running AI workloads specifically: the shared-kernel design means a single bug in runc, the low-level runtime that actually builds and manages containers, can compromise the host no matter how carefully the container sitting on top of it was configured. The vulnerability lives below the layer you control. Lock down every capability, drop every unnecessary permission, and you can still lose, because the flaw was never in your configuration to begin with.
The runc vulnerability class: how symlinks, bind mounts, and file descriptor leaks break the container boundary
runc sits underneath Docker, containerd, and CRI-O, so a runc bug is never just a Docker problem. It spreads to every platform built on top, including Kubernetes clusters at every major cloud provider.
CVE-2024-21626, known as "Leaky Vessels," set the template. A file descriptor leak in runc's container initialization process let a process running inside the container reach host filesystem paths it was never supposed to see. No kernel exploit needed. The flaw sat in runc's own logic, in the plumbing that sets up the container in the first place, and that told researchers, and attackers, exactly where to look next.
The 2025 runc trifecta, CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, followed the same script. All three abuse symlinks and bind mounts to write to host paths from inside a container, and none need a kernel bug at all. Disclosed in November 2025, they hit Docker, containerd, and CRI-O across the board, and got fixed in runc 1.2.8 and later, 1.3.3 and later, or 1.4.0-rc.3 and later. Running an older runc version underneath any of those platforms? The fix isn't optional.
Standard image scanners check what's baked into an image before it runs, and these CVEs exploit a different layer entirely: the runtime interface between the container and the host, active while the container is running. eBPF-based kernel monitoring watches system calls as they happen, which covers the gap a static scan leaves. Four CVEs, one pattern. Attackers don't need a novel kernel zero-day to get out; they need the interface between the runtime and the host, and that interface gets bigger every time someone bolts on a new runtime feature.
Privilege escalation inside the container: capabilities, root users, and writable sockets
Docker's defaults were built for developer convenience, not least privilege. Containers run as root unless someone explicitly sets it up otherwise, and plenty of AI workload images inherit this default without anyone going back to fix it, because fixing it takes time and root just works.
Linux capabilities make it worse. Docker drops some by default but keeps a fairly wide set turned on, and capabilities like CAP_SYS_ADMIN, CAP_NET_ADMIN, and CAP_DAC_OVERRIDE each open a distinct path toward escalation if a process inside the container gets compromised. None of these are exotic; they're standard Linux capabilities that exist for legitimate administrative reasons, which is exactly why leaving them switched on for workloads that don't need them is dangerous.
Then there's the Docker socket. It deserves its own space here, because it's quietly one of the most consequential defaults in the whole ecosystem. Mounting /var/run/docker.sock into a container hands that container de-facto root access to the host: it can now spawn new containers, including privileged ones, through the Docker daemon itself. This shows up constantly in CI/CD pipelines and in agent tool-use setups built on Docker-in-Docker, and people underestimate it routinely because it looks like a convenience feature rather than a privilege boundary someone just erased.
CVE-2025-9074, rated 9.3 on the CVSS scale and fixed in Docker Desktop 4.44.3, showed the socket isn't even the only path in. A malicious container could reach the Docker Engine and launch more containers without any socket ever being mounted. For AI agents, this matters because an agent with shell-execution or filesystem-write access is already one misconfigured capability or one writable socket away from doing exactly this, and it doesn't need an attacker's intent baked in anywhere. It just needs the access to already be sitting there, and some reason, however innocent, to use it. Data from 2022 found that 75% of container images carry high or critical vulnerability issues. That's most of what's running in production, right now, today.
Image poisoning and supply chain compromise: how malicious code enters before the container starts
AI workload images pull from more places than a typical service does: base OS layers, ML framework wheels, model weight files, agent framework packages, each from a different registry or package index. Every one of those is a place someone could slip in something that doesn't belong there.
The vectors themselves aren't new, but they turn up more often in AI pipelines than most people account for. Typosquatting on PyPI and Hugging Face puts malicious packages a single misspelling away from popular ML libraries. A compromised upstream base image, say a poisoned python:3.11-slim layer, spreads silently into every image built on top of it. Model weight files pulled from unverified sources carry their own risk too, particularly when they use pickle-based serialization, a format that can embed code executed the moment the weights load, without review, without scanning, just run.
AI agent frameworks add a layer most supply-chain thinking hasn't caught up to yet: the framework itself is part of the attack surface now. Langflow's CVE-2025-3248, rated 9.8, made it onto CISA's Known Exploited Vulnerabilities catalogue, so real teams got hit, not hypothetical ones. A related flaw, CVE-2025-34291, let attackers skip authentication in Langflow entirely and run arbitrary Python code. There's also an odd twist buried in the remediation pipeline itself: research has found that when LLMs generate patches meant to fix security vulnerabilities, those patches introduce new vulnerabilities in 9.5% of cases, even while successfully fixing the one they targeted. The fix can be part of the problem, which is a strange sentence to write but there it is.
Prompt injection stretches "supply chain" further than most security teams are used to thinking about it. A 2026 disclosure involving Snowflake's Cortex Code CLI, fixed in version 1.0.25 that February, showed indirect prompt injection combined with weak command validation letting AI-generated instructions skip human-in-the-loop approval and escape sandbox mode entirely, leading to arbitrary code execution and access to cached credentials. The supply chain for an AI workload extends beyond its image layers now, reaching into whatever the model happens to read.
Image signing, digest pinning, private registries with admission control, software bills of materials: all of it still matters. It just can't account for code the model writes after the image has already started running.
Insecure defaults and misconfiguration as the everyday attack surface
Most real-world AI workload compromises don't need a novel CVE at all. They exploit defaults nobody bothered to change, which is a less dramatic story but a far more common one.
The --privileged flag is the obvious example. It turns off namespace isolation entirely and hands the container host-level access, and it still turns up in production because it made a debugging session easier once and nobody removed it afterward. Mounting sensitive host paths, /etc, /proc, a cloud provider's instance metadata endpoint, into a container at launch is another. So is exposing container ports with no firewall behind them; AI agent APIs bind to 0.0.0.0 during development all the time, for convenience, and that setting rides straight into production without anyone noticing. Secrets passed as plain environment variables round it out: CVE-2025-3911, fixed in Docker Desktop 4.41.0, showed that anyone with read access to Docker Desktop's log files could read environment variables stored there.
AI workloads pile their own version of this on top. Agent orchestration frameworks often need broad filesystem or network access just to do tool use at all, and rather than scope that access per-agent or per-task, operators tend to grant it globally, because scoping it right takes real design work and granting it globally is far quicker. GPU sharing setups bring their own exposure: CVE-2025-23266 hit the NVIDIA Container Toolkit up to version 1.17.7 running in CDI mode, opening a privilege surface specific to workloads that need GPU access. Registry Access Management policies, meant to control which images can even be pulled, turned out not to be enforced under certain configurations in Docker Desktop 4.41.0, tracked as CVE-2025-4095, and the gate itself could be walked around silently.
A container that survives every CVE on this list can still be wide open laterally, just from networking, volume mounts, and capability sets left sitting at their defaults. Defaults aren't neutral. They're a decision, made by someone else, that most teams never go back and revisit.
Why the shared-kernel model fails specifically when AI agents generate and execute code at runtime
What actually changes when the workload is an agent instead of a normal service? In a conventional containerized app, the code inside is known ahead of time, a person reviewed it, and it stays the same from one deploy to the next. The threat model is about what comes in from outside: bad input, a malicious request, an attacker probing an API. The code itself isn't the threat.
AI agents flip that around. The code gets written at the moment it runs, the inputs that shaped it may already sit under an attacker's influence, and the agent runs what it just generated immediately, with no human standing between the generation and the execution. There's no review gate, no pause.
Put the earlier sections next to each other and the danger sharpens fast. A single unpatched runc CVE, combined with an agent that has shell-execution capability, combined with a prompt injection buried in whatever the agent is reading, adds up to a container escape without the attacker lifting another finger. These vulnerability classes don't need a skilled human operator chaining them together step by step. A capable enough agent is already the exploit vehicle, running the whole chain on its own, simply by doing what it was built to do: act on what it's given.
Performance data backs up how central this runtime layer really is. Research from Augment Code found that OS-level execution, meaning tool calls and container or agent initialization, accounts for 56 to 74% of end-to-end task latency in agent workloads. That's the dominant layer, both for speed and, as it turns out, for risk. Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027, largely because of the real cost and difficulty of running agents safely in production, security and governance chief among the reasons cited. A bug can get patched once someone finds it. A model's behavior at runtime resists that kind of fix, because the model isn't a fixed artifact; it writes something new every time it runs.
Isolation technologies that address what Docker's shared-kernel model cannot: gVisor, microVMs, and purpose-built sandboxes
Three approaches close the gap Docker's shared kernel leaves open, and they differ mainly in how much of the host kernel they take out of the equation entirely.
gVisor intercepts system calls before they ever touch the host kernel, using a user-space kernel it calls the Sentry process. This shrinks the host kernel's exposure a good deal, meaningfully stronger than a stock Docker container. It's not the same as giving each workload its own dedicated kernel, though. The Sentry process still runs on top of the host kernel, so the shared-kernel risk gets reduced, not removed. There's a real cost too: I/O overhead runs 10 to 30%, which matters on workloads that read and write files heavily or push a lot of network traffic.
Firecracker and Kata, the microVM approach, go further. Each workload gets its own dedicated kernel, so the shared-kernel attack vector is architecturally gone rather than merely reduced. Firecracker boots in roughly 125 milliseconds using under 5 MiB of memory overhead, and production platforms have shown resume-from-standby times under 25 milliseconds; fast enough that VM-level isolation is now practical for agent workloads that need to respond in real time. Every CVE covered in this piece, the runc trifecta, Leaky Vessels, CVE-2025-9074, all of them exploit the interface between the container runtime and the host kernel. In a microVM, that interface simply isn't there to exploit in the first place.
Beyond the isolation model itself, a newer category of purpose-built sandbox has shown up specifically for running untrusted or AI-generated code, pairing strong isolation with what agents actually need day to day: fast startup, the ability to hold state across a long-running session, and the compliance controls enterprises expect, Daytona, for instance, is cloud infrastructure built around that specific execution model, provisioning isolated sandboxes in under 90 milliseconds for AI-generated code. Whether the runtime is open source and auditable matters here, because a team running code it can't fully vet shouldn't also have to run that code inside an execution service it can't fully vet either. What Kubernetes-native efforts like the agent-sandbox project's Sandbox custom resource point to is a stack where this becomes a standard layer, not a niche add-on. Docker's shared-kernel model was a reasonable bet for a world where a person wrote the code inside a container and reviewed it before it ran. That world isn't the one agents operate in anymore, and the isolation layer is still catching up.
