Docker’s 1MB authz bypass exposes a decade-old policy gap

At a glance

What this is: Cyera found a Docker Engine authorization bypass where request bodies over 1MB are dropped before AuthZ plugins inspect them, allowing privileged container creation.

Why it matters: For IAM and security teams, this shows that control points around container runtimes must fail closed, because invisible request truncation can nullify policy enforcement across NHI and workload identities.

By the numbers:

• Docker is the world’s most widely used container runtime, with 92% adoption among IT professionals.
• Docker processes over 20 billion container image pulls per month.
• CVE-2026-34040 carries a CVSS 8.8 High score.

👉 Read Cyera’s analysis of Docker’s 1MB authorization bypass and host access risk

Context

Docker container security depends on a simple assumption: the authorization layer sees the same request the daemon will execute. In this case, that assumption fails when oversized request bodies are silently dropped before AuthZ plugins can inspect them, creating an authorization gap rather than a configuration mistake.

That matters because container runtimes sit inside NHI governance, CI/CD pipelines, and platform operations. When policy checks can be bypassed by request size instead of by privilege, the control plane no longer reflects the actual action taken on the host.

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 request bodies create a security risk in container platforms?

A: Oversized request bodies become dangerous when the security gate truncates them but still lets execution continue. The control then sees less than the actor submitted, which can hide privileged settings or mount directives. In container platforms, that turns a size threshold into a policy bypass.

Q: How can security teams tell whether their container controls are really working?

A: They should test whether the enforcement point receives the exact same request that the daemon acts on, including edge cases such as oversized bodies, chunked transfer, and empty-body anomalies. If the policy layer can be fed a different view of the request, the control is not reliable.

Q: Who is accountable when a Docker API policy bypass exposes host secrets?

A: Accountability sits with the platform team that owns runtime access, the security team that defined the policy boundary, and the operators who allowed privileged container creation paths to remain reachable. In practice, this issue should be reviewed under workload identity, privileged access, and container governance controls.

Technical breakdown

How Docker AuthZ middleware can fail open on request size

Docker’s authorization plugin model places a policy decision between the API request and the daemon. The plugin is supposed to inspect the body of a container-creation request before the engine acts on it. In the vulnerable path, oversized bodies are truncated or omitted, so the plugin receives nil while the daemon still processes the full payload. That creates a split-brain decision path: policy evaluates an empty request, execution receives the real one. The bug is not in container isolation itself. It is in request mediation, where the control layer loses parity with the execution layer.

Practical implication: Treat middleware truncation as a security failure, not a harmless limit.

Why oversized request bodies break authorization semantics

Authorization depends on complete input. If a control sees only part of a request, it cannot make a correct allow-or-deny decision, especially when fields such as privileged mode or host mounts sit in the omitted portion. In this case, the bug class is incorrect authorization, not a parsing error. The body-size threshold turns into an attacker-controlled bypass condition because the security decision is made on incomplete data. Any system that inspects requests through a separate plugin, proxy, or filter has the same structural risk if oversize handling does not fail closed.

Practical implication: Validate that every authorization gate rejects oversize or truncated input instead of passing partial data onward.

Why fail-closed behavior matters more than the exact size limit

The patched design raises the body limit and, more importantly, rejects requests that exceed it instead of dropping the body and continuing. That distinction matters more than the numeric threshold. A larger limit still leaves authorization intact only if the control layer either forwards the full body or blocks the request entirely. Once a middleware layer can silently downgrade the evidence available to policy, the security decision becomes unreliable. This is a general pattern in gateways, WAFs, and authorization proxies, not just Docker.

Practical implication: Review every proxy or gate for silent truncation paths that preserve execution but erase evidence.

Threat narrative

Attacker objective: The attacker’s objective is root-level access to the host and the NHI credentials stored on it, enabling broader cloud and platform compromise.

1. Entry occurs when an attacker reaches the Docker API through network-accessible management paths or CI/CD tooling.
2. Escalation occurs when a padded request exceeds the AuthZ body limit, causing the plugin to see no body while the daemon still creates the container.
3. Impact occurs when the privileged container gains host filesystem access and exposes credentials, keys, and orchestration secrets.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Middleware body truncation is an authorization failure, not an implementation quirk. When the policy engine sees an empty or partial request while the daemon executes the full payload, the control plane stops representing the real action. That breaks the basic assumption that authorization examines the same artifact that will be executed. Practitioners should treat any silent truncation path as a governance defect, because the denial decision no longer maps to the executed request.

The named concept here is request-body parity collapse. Authorization systems are designed for conditions where input integrity is preserved from gate to executor. That assumption fails when body limits, buffering, or drainage logic allow one component to see nothing while another acts on everything. The implication is not just a stronger filter. It is that policy confidence disappears whenever the enforcement path can diverge from the execution path.

Container runtime controls belong in the NHI governance conversation. Docker API access, AuthZ plugins, service identities, and CI/CD automation all operate as non-human access surfaces. When one size check can nullify policy, the problem is not merely container hardening. It is unmanaged workload authority. Practitioners should reassess which runtime controls are actually enforcing identity policy and which ones only appear to.

OWASP-style incorrect authorization remains a live failure mode because middleware can hide the evidence from the decision engine. This is not a new bug pattern in a new stack. It is the same class of trust failure seen whenever security middleware truncates or transforms input before policy evaluation. The broader lesson is that authorization cannot be considered reliable unless the control layer either sees the whole request or stops the request entirely.

Security architecture should stop assuming that an authorization plugin is the final authority. In this class of failure, the plugin is merely one participant in a broken chain of custody for the request body. The field needs to reframe runtime policy as an integrity problem, not just a permissions problem. Practitioners should decide whether their container, proxy, or gateway controls can prove evidence continuity before trusting the allow decision.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• From our research: 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent, according to The State of Secrets Sprawl 2025.
• For the next step: Review NHI Lifecycle Management Guide for lifecycle controls that keep runtime identities and secret exposure from becoming a host-level event.

What this signals

Request-body parity collapse is the right way to think about this class of failure. Once a control can inspect one version of the request while another component executes a different version, policy no longer describes reality. That is the governance gap teams need to close in Docker API design, gateway inspection, and workload identity enforcement.

With 4.6% of public GitHub repositories already containing at least one hardcoded secret, per The State of Secrets Sprawl 2025, runtime control failures quickly become secret-exposure events when container access reaches the host. Teams should assume the impact is credential theft first and policy bypass second.

Practitioners should align container governance with NIST Cybersecurity Framework 2.0 and The 52 NHI breaches Report by validating that inspection, denial, and execution stay coupled under load, not just in test cases.

For practitioners

• Audit every body-handling authorization path Check Docker, proxy, and API gateway controls for any path where oversized or truncated input reaches execution while the policy layer sees incomplete data. Look for silent drop, buffering, and fallback-to-empty behaviors.
• Require fail-closed behavior on oversize requests Reject requests that exceed policy inspection limits before they reach the daemon, rather than forwarding an empty or partial body to the authorizer. Verify that truncation never becomes an allow path.
• Test container policy with padded requests Use oversized container-create requests to confirm that privileged mode, host mounts, and command overrides are visible to the enforcement layer under real network transport conditions.
• Map Docker API access to workload identity governance Treat Docker API clients, CI/CD service accounts, and platform automation as governed non-human identities and review which ones can create privileged containers or mount host paths.
• Validate host-secret exposure paths after runtime compromise Confirm whether container escape scenarios can read cloud credentials, SSH keys, or kubeconfig from the host, then separate those secrets from runtime nodes with tighter identity boundaries.

Key takeaways

• Docker’s vulnerable AuthZ path turns request-size handling into an authorization bypass when the policy layer sees less than the daemon executes.
• The practical risk is host compromise plus secret exposure, because privileged containers can read credentials, kubeconfigs, and SSH keys from the host.
• Teams should test for silent truncation, enforce fail-closed behavior, and govern Docker API clients as workload identities rather than informal admin tooling.

Key terms

• Authorization Middleware: Authorization middleware is the control layer that inspects a request before the target system acts on it. In container platforms, it should enforce policy on the same body and headers that the runtime will execute, otherwise the decision can diverge from reality and create a bypass.
• Fail-Closed Behavior: Fail-closed behavior means the system rejects an unsafe or incomplete request instead of continuing with partial information. For runtime identity and container governance, this matters because silent truncation, buffering, or parsing loss can erase the evidence policy needs to make a correct decision.
• Request-Body Parity: Request-body parity is the condition where the policy layer and the execution layer observe the same request content. If one component sees a truncated or empty body while another executes the full payload, authorization is no longer trustworthy and the control path has become inconsistent.
• Privileged Container: A privileged container runs with reduced isolation and can access host resources far beyond a standard workload. In identity terms, it represents elevated runtime authority, so any bypass that allows privileged creation becomes a workload access and secret exposure problem, not just a container hardening issue.

Deepen your knowledge

Docker authorization bypasses and workload identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for container runtimes and CI/CD access, it is worth exploring.

This post draws on content published by Cyera: One Megabyte to Root: How a Size Check Broke Docker’s Last Line of Defense. Read the original.