New Docker Vulnerability: Bypass All Controls with a Simple Payload
A newly discovered critical CVE vulnerability in Docker Engine could allow attackers to bypass authorization plugins and potentially gain unauthorized access to the underlying server system. CVE-2026-34040 (CVSS 8.8) enables anyone to completely bypass the authorization control plugin (AuthZ) on Docker Engine and seize root privileges on the physical server, simply through an HTTP POST request larger than 1MB. The current surge of AI Coding Agent models operating within Docker Sandboxes has turned this decade-old design flaw into a deadly leverage, allowing for the theft and leakage of source code and AWS Identity from deep within enterprise infrastructure.
Summary of the risk
The CVE-2026-34040 vulnerability in Docker Engine allows attackers or AI Agents to completely bypass authorization control mechanisms by sending an HTTP request larger than 1MB. As a result, attackers can create a privileged container and gain root access to the physical server, stealing AWS credentials, SSH keys, or Kubernetes configs without needing to exploit complex code.
This risk directly impacts 92% of enterprise infrastructures using Docker, especially in CI/CD deployment environments or increasingly popular AI coding sandboxes. The issue lies in the "fail-open" design of the AuthZ middleware over the past decade.
Description of the Vulnerability & Scope of Impact
CVE ID: CVE-2026-34040 CVSS v3.1: 8.8 (High) CWE: CWE-863 (Incorrect Authorization) Affected Environment:
Docker Engine: All versions from v1.10 (released February 2016) to before v29.3.1.
Docker Desktop: Versions older than v4.66.1 (version 4.66.1 includes Engine 29.3.1).
Mirantis Container Runtime (MCR): Includes the latest version of MCR (v29.2.1) at the time the flaw was discovered (MCR shares the upstream Moby with Docker Engine, so it also shares this risk).
Systems NOT affected: Kubernetes clusters using containerd or CRI-O (default from K8s v1.24), as well as Podman. This flaw specifically resides in Docker's internal AuthZ framework.
Condition: The Docker system must rely on AuthZ plugins (e.g., Open Policy Agent - OPA, Prisma Cloud, Casbin) to block dangerous container creation behaviors, and the Docker API port is exposed directly (or indirectly through sandboxes). Attack vector: Network / Local — No user interaction required, low privileges. The attacker or agent only needs to send an API request with padding that exceeds the size limit.
Docker Architecture and the AuthZ "Gatekeeper"
To understand why incorrect size blocking leads to server takeover, we need to look at Docker's core architecture. Unlike virtual machines (VMs) with independent kernels, Docker containers operate by sharing a single kernel of the physical host system. The isolation between them is entirely virtual walls structured through Linux features (cgroups, namespaces). If this wall is breached, anything within the container immediately gains privileged access to the underlying system.
To protect the system in an enterprise environment, organizations establish rules: not everyone or every task is allowed to create containers. This control process is assigned to AuthZ Plugins (Authorization Plugin).
Every REST API request sent to the Docker Engine (such as POST /containers/create) passes through a checkpoint (AuthZ middleware). The middleware reads the content, repackages it, and submits it to the AuthZ Plugin for approval. If AuthZ detects that the payload intends to create a container with dangerous flags (like Privileged: true or root mapping), it will block the request. The CVE-2026-34040 vulnerability occurs not because AuthZ lacks intelligence, but because the checkpoint itself "hides" data before passing it to AuthZ.
Exploit mechanism
The vulnerability stems from how Docker AuthZ middleware processes input data. Since version 1.10 (released early 2016), Docker uses the constant maxBodySize = 1048576 (equivalent to 1MB). When a request (like POST /containers/create) is received, if the request body size is less than 1MB, the entire content is packaged and sent to the AuthZ plugin for inspection (e.g., checking for the Privileged: true flag). However, if the body exceeds 1MB, the middleware applies a trimming logic (drainBody) and sends a RequestBody: nil to AuthZ.
Since the plugin receives an empty payload, it sees no reason to deny and defaults to "allow." Although the plugin's input is trimmed, the Docker daemon behind it processes the entire actual payload, including any malicious content. Notably, this flaw is essentially an incomplete patch for CVE-2024-41110 (a vulnerability exploited through a 0-byte body since 2024). The attacker doesn't need any binary exploit techniques. By simply adding a junk data field about 2MB long into the JSON, the command to create a container with root mount access to the /host system still gets through.
Technical Analysis PoC
To better illustrate, here is a detailed analysis of the payload forming the PoC exploiting this vulnerability. A typical API request to create a privileged container usually has a compact structure and will be immediately blocked by the AuthZ Plugin:
However, in the actual PoC, the attacker (or malware executed by an AI Agent) will insert a harmless but extremely large field into the JSON structure. This field is ignored by the Docker Engine parser as it holds no configuration significance, but it serves the static purpose of inflating the Content-Length of the HTTP request beyond the 1 Megabyte threshold.
The Docker Engine's seamless processing of this payload: Middleware reception: The middleware detects a Content-Length indicating a packet of about 1.5MB (exceeding the 1048576 limit). The drainBody function activates, proactively refusing to copy this body to the AuthZ station to prevent RAM overflow.
AuthZ Plugin blinded: The AuthZ Plugin review station encounters an empty HTTP payload from the middleware (len=0). Without detecting the keyword Privileged: true or any malicious indicators, AuthZ cannot match against the block list and automatically returns "Allow" due to its "fail-open" design. Docker Daemon Core execution: Unlike the review station, the core architecture behind it processes the complete 1.5MB body originally sent from the client. It successfully parses the JSON structure and ignores the AuthZ_Bypass_Padding junk field. The container creation command is authorized, leading to a privileged container mapping to the root directory /:/host_root, allowing the target to steal system secrets.
Actual exploitation observed
The current CVSS score is 8.8 instead of 10.0, depending on the assessment that "Local access" to the Docker socket is required. However, with the prevalence of AI Agents (like OpenClaw), the context has shifted. AI Coding Agents running in Docker Sandboxes are often pre-mounted with access to the Docker daemon for convenient test environment setup. Cyera Research has demonstrated a highly realistic attack kill chain PoC:
The attacker creates a repo containing a Prompt Injection on GitHub. The developer instructs the Agent to clone the repo. The compromised Agent uses Python to send a REST request over 1MB to the internal Docker socket. It successfully creates a privileged container, reads the contents of /host/root/.aws/credentials, and sends them out.
Even without intentional sabotage, agents (like Claude Code) often try to bypass blocklists to "complete tasks." This bypass is now easily achieved through an inflated payload. At the infrastructure level, malicious software repos inserting commands via npm postinstall (similar to the campaign targeting Axios in March 2026) can fully automate this process.
MITRE ATT&CK Mapping
| Tactic | Technique | Description |
|---|---|---|
| Execution | T1059.006 - Python | Use a Python script to prepare the request. |
| Execution | T1610 - Deploy Container | Create an unauthorized container to bypass the AuthZ gate |
| Privilege Escalation | T1611 - Escape to Host | Escape sandbox using a privileged container |
| Credential Access | T1552.001 - Credentials In Files | Extract AWS config directly from the host machine's disk. |
| Lateral Movement | T1078 - Valid Accounts | Use credentials to infiltrate Cloud/K8s. |
IOC
Review all running containers with sensitive privileges: docker inspect --format '{{.Name}} Privileged={{.HostConfig.Privileged}} Binds={{.HostConfig.Binds}}' $(docker ps -aq) If a container is found with Privileged=true and Binds=[/:/host] during the alert period for body size, the system is almost certainly compromised.
Response steps: Export logs and forensic image of the suspicious container. Delete any tokens (AWS, Azure, K8s) that may have been leaked if /host was successfully mounted. Immediately update to Docker 29.3.1.
Analysis
CVSS 8.8 High accurately reflects the consequences of the incident. According to observations by the FPT IS SOC expert team, the greatest risk to Vietnamese enterprise systems today is not Docker being exposed to the Internet, but the broad attack surface from CI/CD tools (GitLab Runner, Jenkins) or sandbox environments for internal application development. Many technology and financial organizations in Vietnam are trending towards using AI/LLMs to process internal code; this vulnerability turns these "AI assistants" into espionage gateways, silently bypassing AuthZ barriers without any illegal access warnings recorded on monitoring plugins.
Deeper still, the maxBodySize limit structure has existed for 10 years in Docker's source code, using a "fail-open" design (errors are ignored as correct). This is a fatal mistake for any secure middleware architecture. The previous stumble through the CVE-2024-41110 vulnerability (content-length = 0) was a warning, and this CVE is the conclusion: You cannot entrust the safety of the kernel to ambiguous data processing checkpoints.
Recommended actions
Immediate (0-24h)
Check Docker Engine version: Run the command docker version --format '{{.Server.Version}}'.
Add blocking rules (WAF/Reverse Proxy) for sensitive endpoints: Apply client_max_body_size 512k in Nginx before the Docker socket API for the endpoint /v[\d.]+/(containers/create|exec/.+/start).
Short-term (1-7 days)
Update the Docker Engine version to >= 29.3.1. This patch eliminates the old processing function, expands the limit to 4MB, and changes the architecture to block requests (fail-closed) if the body exceeds the limit.
For Docker Desktop users, update to version 4.66.1.
If you can't upgrade immediately, use Rootless Docker or namespace remapping (--userns-remap). This approach helps limit the blast radius to a regular user level if a privileged container is accidentally invoked.
Long-term
- Reevaluate the integrated AI sandbox architecture. Use separate reverse proxies for the socket (docker-socket-proxy) to completely block AI from accessing container creation APIs instead of relying entirely on AuthZ plugins.
Refer
One Megabyte to Root: How a Size Check Broke Docker’s Last Line of Defense | Cyera Research
Docker CVE-2026-34040 Lets Attackers Bypass Authorization and Gain Host Access
Docker Security Bypass (CVE-2026-34040): Critical Patch & Mitigation |Cyera Research | Cyera Blog
