Docker Auth Bypass Gives Attackers Full Host Access

A high-severity vulnerability in Docker Engine allows attackers to completely bypass authorization plugins and gain root access to the host system. The flaw, tracked as CVE-2026-34040, requires nothing more than a single HTTP request padded beyond 1MB.

Docker released Engine 29.3.1 on April 7 to address the issue. Organizations running containers with AuthZ plugins should patch immediately.

The Vulnerability

CVE-2026-34040 stems from an incomplete fix for CVE-2024-41110, a maximum-severity authorization bypass discovered in July 2024. When Docker patched the original flaw, they failed to account for oversized HTTP request bodies.

Here's how the attack works: Docker's authorization plugins inspect incoming API requests to enforce access controls. But when a request body exceeds 1MB, the daemon forwards it to the plugin without the body content. The plugin approves the request based on headers alone—then Docker processes the full body, including malicious container creation parameters.

An attacker with any level of Docker API access can exploit this by padding a container creation request with junk data. The resulting container runs with root privileges and full host filesystem access.

Why This Matters

The attack is trivial. No exploit code required. No special privileges needed. Just one HTTP request.

This is particularly concerning for organizations running AI agents or automated tools inside Docker containers. A prompt injection attack or routine debugging task could inadvertently trigger container creation—and if that request happens to be padded to 1MB, it bypasses all authorization controls.

The vulnerability carries a CVSS score of 8.8 (High). It affects any Docker deployment using authorization plugins for access control, including:

• Multi-tenant container environments
• CI/CD pipelines with restricted Docker access
• Managed container platforms
• Development environments with security policies

Organizations that rely solely on AuthZ plugins for container security have a gap. The plugin thinks it approved a harmless request; Docker actually executed a privileged one.

Affected Versions and Patches

Docker Engine versions prior to 29.3.1 are vulnerable. The fix ensures request bodies are properly forwarded to authorization plugins regardless of size.

For teams that cannot immediately upgrade, Docker recommends these workarounds:

1. Avoid AuthZ plugins that inspect request bodies - If your security model depends on body inspection, it's broken until you patch
2. Restrict Docker API access - Limit who can interact with the Docker socket using host-level controls
3. Run Docker in rootless mode - Eliminates the root privilege escalation even if containers are created
4. Use userns-remap - Maps container root to unprivileged host user

The Bigger Picture

This is the second major authorization bypass in Docker's AuthZ system in under two years. The original CVE-2024-41110 had a CVSS of 10.0—a complete auth bypass with no mitigations. CVE-2026-34040 is slightly less severe only because it requires the attacker to already have some Docker API access.

The pattern suggests AuthZ plugins may not be the right security boundary for container workloads. Network segmentation, pod security policies (in Kubernetes), and runtime security tools like Falco provide defense-in-depth that doesn't depend on a single plugin inspection.

For teams running containers in production, this is worth a conversation about where trust boundaries actually exist. If a malicious actor reaches your Docker socket, what happens next? The answer shouldn't be "they get root on the host."

Remediation Steps

1. Upgrade Docker Engine to 29.3.1 immediately on all hosts running AuthZ plugins
2. Audit container creation logs for requests exceeding 1MB in the past 30 days
3. Review API access to Docker sockets—apply principle of least privilege
4. Consider rootless Docker for development environments where full privileges aren't required
5. Add runtime monitoring to detect privileged container creation events

Organizations using managed container services should verify with their provider that the underlying Docker infrastructure has been patched. The vulnerability affects the Docker daemon itself, not container images or orchestration layers.