Docker fixes AuthZ bypass bug that created containers with excessive privileges

Docker has patched a vulnerability that lets an attacker bypass AuthZ checks, which then lets them create containers with excessive privileges or other restricted qualities, Cyera disclosed Tuesday.  

The flaw, tracked as CVE-2026-34040, lies in the middleware between the Docker API and any AuthZ plugin used to enforce an organization’s container permissions policies. Because the vulnerability affects the Docker middleware that passes requests to the plugins, Docker users are affected regardless of which specific AuthZ verification plugin they use.

An attacker with sufficient access to the Docker API can exploit the flaw by crafting an HTTP request with a size greater than 1 megabyte, which causes the Docker middleware “gate” to not pass the request body to the AuthZ plugin. Despite this, the Docker daemon still processes the full body, which let containers with disallowed characteristics, such as ‘“Privileged”: true’, get created.

“Imagine a bouncer at a club who checks IDs. But there’s a rule: if the line has more than 100 people, the bouncer goes home. The club still lets everyone in. They just don’t check anyone’s ID anymore. That’s this bug,” the Cyera researchers wrote.

Cyera describes this 8.8 flaw as an “incomplete fix” of a previous 10.0 flaw tracked as CVE-2024-41110. The flaw allowed for AuthZ bypass if an attacker declared the Content-Length of zero but still included a request body. The middleware would send an empty body to AuthZ plugins, but the actual body would still be processed by the daemon.

CVE-2024-41110 was originally fixed in 2019, but the patch was not carried forward to all later versions, leading to a regression issue that was ultimately resolved in 2024. However, Cyera found that none of the patches addressed the 1MB maxBodySize that caused requests of 1MB or larger to also bypass AuthZ.

The researchers further demonstrated how attackers could exploit the AuthZ flaw CVE-2026-34040 in a scenario involving an AI coding agent running inside a Docker-based sandbox. A prompt injection or supply chain attack could influence the agent to leverage the flaw and create a privileged container with the entire host filesystem mounted. The agent could then exfiltrate sensitive information and credentials from the system.

“This is not just a privilege escalation. The attacker now has the actual data and secrets that the authorization policy existed to protect: customer records stored in S3, database credentials, production SSH keys, and Kubernetes cluster access tokens,” the researchers said.

Docker fixed the issue by both increasing maxBodySize to 4MB and ensuring any requests with bodies greater than 4MB are fully rejected and not passed to the daemon. They also removed the drainBody() function, which let bodies exceeding the size limit be silently dropped before passing requests to AuthZ.

Users should update to Docker Engine version 29.3.1 or later and can also check for any potential exploitation by searching Docker daemon logs for drainBody warnings and auditing recent container creating events, although there's no indication the vulnerability has been exploited in the wild.

Cyera also recommends restricting Docker API access only to trusted IPs and authenticated clients and avoid using AuthZ as the only line of defense.