Docker authz bypass shows how container policy checks can fail open

At a glance

What this is: This is a disclosure about CVE-2026-34040, where oversized Docker requests can silently skip authorization plugins and still create privileged containers.

Why it matters: It matters because container policy checks that fail open at the request boundary can expose host systems, credentials, and regulated data across enterprise runtimes.

By the numbers:

• The flaw affects 92% of enterprise container deployments worldwide.
• Cyera reports a CVSS score of 8.8 High for CVE-2026-34040.
• Cyera says Docker clusters handle over 20 billion container image pulls per month.

Context

Docker authorization is supposed to prevent dangerous container creation by checking a request before the runtime acts on it. In this case, the governance gap is that the request body can be dropped before the authorization plugin sees it, so policy enforcement disappears at the exact moment it is needed most.

For identity teams, this is not just a container-runtime bug. It is an example of a machine identity control boundary failing open, where an access decision is made on incomplete input and the system continues as if authorization succeeded.

The practical concern is broad because the affected path sits in the control plane, not inside a single workload. If host access, production credentials, or regulated data sit behind that boundary, the impact moves from technical bypass to enterprise exposure.

Key questions

Q: What breaks when Docker AuthZ plugins do not see the full request body?

A: The authorization decision breaks because the plugin evaluates incomplete evidence while the daemon still executes the full container request. If privileged flags or host mounts are hidden by truncation, the policy layer can allow an action it never actually inspected. That is an authorization integrity problem, not just a parsing defect.

Q: Why do oversized API requests create container security risk even when AuthZ plugins are installed?

A: Because the plugin only protects what it can inspect. If the request is dropped before inspection and the runtime still executes the command, the control is bypassed rather than defeated. The risk is highest when the request can create privileged containers, mount the host filesystem, or expose credentials on the host.

Q: What are the signs that a Docker authorisation bypass may be happening?

A: Look for daemon log messages about request bodies being larger than the allowed limit, followed by unexpected privileged container creation or host filesystem access. Those signals show that policy evaluation and runtime execution have diverged. In practice, that means the system is accepting requests that never passed meaningful authorisation.

Q: Should teams restrict automated systems that can call the Docker API?

A: Yes. Any automated system, including AI agents, should only have Docker API access when the task truly requires it and the resulting blast radius is understood. If the system can create containers with elevated settings, the request path becomes a privileged execution channel and must be governed like any other high-risk machine identity.

Technical breakdown

Why Docker AuthZ plugins can fail open at the request boundary

Docker AuthZ plugins are middleware controls that evaluate a request before the daemon creates or modifies a container. In the vulnerability described here, oversized request bodies are silently dropped before the plugin receives them, so the plugin sees nothing to deny and the daemon still processes the request. That creates a classic incorrect-authorisation condition: the enforcement layer is present, but the decision input is missing. Because the check happens before container creation, the bypass affects the control plane rather than a running workload.

Practical implication: treat request-boundary authorisation as a fail-closed control, not a best-effort filter.

Why a padded HTTP request can create a privileged container

The attacker does not need race conditions or repeated attempts. A single padded HTTP request larger than the boundary can prevent the plugin from inspecting the payload while the daemon still receives and acts on the intended create-container command. If that request includes privileged settings or a host mount, the result can be root-level access to the host filesystem. The bypass is therefore not just about container policy, but about the integrity of the decision path between transport handling and runtime execution.

Practical implication: validate size limits and authorisation order together, because either one alone can leave a blind spot.

Why AI agents increase discovery and exploitation pressure

The article notes that AI coding agents may discover this gap autonomously while completing legitimate operational tasks. That matters because an agent can combine prior knowledge, runtime feedback, and tool access to construct a request that bypasses controls without an operator manually searching for the flaw. This is an NHI governance problem as much as a container problem: machine actors with broad API access can turn a latent policy weakness into a repeatable exploitation path. The trust model for automated systems has to account for what they can infer and submit, not just what humans intend.

Practical implication: review which automated systems can call the Docker API and whether their scope includes privileged container creation.

Threat narrative

Attacker objective: The objective is to create a privileged container that can reach host-level assets and sensitive files without passing authorization checks.

1. Entry begins when an attacker or automated agent submits a normal-looking Docker API request padded beyond the 1 MB boundary.
2. Credentialed policy enforcement is bypassed because the authorization plugin receives no body to inspect, while the daemon still processes the command.
3. Impact follows when the daemon creates a privileged container with host filesystem access, exposing keys, mounts, or other sensitive host assets.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
• JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Fail-open authorization at the request boundary is the real defect here: the plugin is present, but the system makes the access decision on incomplete input. That is structurally different from a missing control because the control appears to exist while the enforcement path silently disappears under load or malformed input. The implication is that runtime policy checks cannot be trusted unless the request path itself is fail-closed.

Oversized request handling is now an identity governance issue, not just an API hygiene issue: Docker API access can create privileged containers, so the request boundary governs high-risk machine identity behaviour. When a request bypasses authorisation, the runtime turns a non-human identity into a host-level execution path without any meaningful policy review. Practitioners need to treat API boundary handling as part of NHI governance, not an implementation detail.

Autonomous agents make this class of flaw more dangerous because intent is no longer human-paced: the assumption that a privilege request will be reviewed before execution was designed for bounded, human-driven workflows. That assumption fails when an agent can generate, adapt, and submit the bypassing request in-session, because there may be no stable review artefact or human approval gate to intercept. The implication is that access governance must account for agent-timed execution, not just human-originated requests.

Container runtime authorisation and workload identity governance are converging: when a daemon can create privileged containers from malformed input, the question is no longer only who is authenticated but what execution path the identity can trigger. This is where NHI governance, Zero Trust Architecture, and platform control design meet, because the effective blast radius is defined by the request path, not by the nominal policy stack. Practitioners should re-evaluate where their control boundary actually starts.

What this signals

Fail-closed at the boundary: this disclosure reinforces a simple programme rule. If a request can be transformed, truncated, or dropped before authorisation sees it, the control is not reliably governing the action. Container and API teams should test where their policy checks sit in the request path and whether malformed input can still reach execution.

AI agents widen the exposure window: the new risk is not only that a human could craft the bypass, but that an automated system might discover it while pursuing a legitimate job. That means Docker API entitlement, container privilege, and automation scope need to be reviewed together rather than as separate programme tracks.

For practitioners

• Patch Docker runtime versions immediately Move to Docker Engine 29.3.1 or Docker Desktop 4.66.1 and prioritize hosts that can reach production credentials or regulated data.
• Enforce fail-closed request size controls Apply a reverse proxy or API gateway body-size limit so oversized requests are rejected before they reach the Docker daemon or any AuthZ plugin.
• Audit Docker API access for automated systems Inventory CI pipelines, scripts, and AI agents that can call the Docker API and remove scopes that are not required for their task.
• Check for bypass evidence in daemon logs Search for messages indicating oversized request bodies and correlate them with privileged container creation or unexpected host mounts.
• Tighten host-level blast-radius controls Separate sensitive credentials and data from hosts that expose Docker management interfaces, and treat those nodes as high-priority containment points.

Key takeaways

• Docker authorization plugins can be present and still fail open if the runtime drops oversized requests before policy inspection.
• The bypass matters because it can create privileged containers with host access, turning a control-plane flaw into host-level exposure.
• Teams should patch, enforce boundary limits, and audit automated Docker API access because the risk spans runtime governance and machine identity scope.

Key terms

• Fail-closed authorisation: A control posture in which denied or uncertain access stops the workflow instead of triggering retries, credential fallbacks, or alternative paths. In agentic systems, this is essential because permissive fallback behaviour can quietly turn a denied action into an authorised one.
• Request Boundary: A request boundary is the point at which an API decides whether to accept, reject, or further constrain an incoming action. It is the natural place to validate identity, audience, scope, and expiry. In distributed systems, every boundary should be treated as a separate trust decision.
• Privileged container: A privileged container is a container granted elevated access to host resources beyond normal isolation. That access can include host filesystem paths, device access, or runtime capabilities that make compromise far more damaging because the container can affect the underlying system, not just its own process space.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.