Researchers warn about a new vulnerability that allows attackers to bypass authorization plug-ins in Docker Engine and gain root-level access to host systems. The flaw has the same root cause as another authorization bypass vulnerability patched in 2024, but the underlying problem has been known since 2016.

Tracked as CVE-2026-34040, the new vulnerability is rated 8.8 (high) on the CVSS scale and was fixed in Docker Engine 29.3.1 and Docker Desktop 4.66.1. If updates cannot be deployed immediately, malicious requests may possibly be filtered out by limiting request size to 512KB.

“The Docker API is accessed over the network (TCP/TLS) in most enterprise deployments, CI/CD systems, and management platforms,” researchers from security firm Cyera said in a report. “This is a single HTTP request with no race conditions or timing dependencies. If an attacker (or AI agent) has Docker API access restricted by an AuthZ plugin, they can bypass it.”

The 10-year-old AuthZ gap

The Docker Engine doesn’t have role-based authorization by default, which means that any user who can access the Docker API can execute all Docker commands. To enforce more granular controls, enterprises rely on various third-party and custom Docker AuthZ plug-ins, a feature that has existed in Docker Engine since 2016.

In 2018, researchers realized attackers could bypass all restrictions enforced by AuthZ plug-ins by sending requests with Content-Length set to 0 to the Docker daemon, which would then forward them to the AuthZ plugins by stripping the request bodies. The plug-ins would automatically approve such requests thinking there was no command in it, but the Docker Engine would then execute the commands in the request body that was stripped.

The issue was fixed in Docker Engine v18.09.1 released in January 2019, but the fix was not included in later Docker Engine versions starting with 19.03, causing a regression and a new vulnerability tracked as CVE-2024-41110. The flaw was eventually patched in July 2024 in versions 23.0.14, 26.1.4, and 27.1.0.

No one checked oversized requests

While the previous authorization bypass was triggered when request Content-Length was set to 0, no one checked at the time what would happen in the same function if the request exceeded a certain size.

“When an API request body exceeds 1MB, Docker’s middleware silently drops the body before your authorization plugin sees it,” the Cyera researchers found. “The plugin, seeing nothing to inspect, approves the request. The Docker daemon then processes the full body and creates the requested container, potentially granting full host filesystem access.”

This is essentially the same bug class with the same root cause, but using 1MB request padding instead of zero length. Because the AuthZ plug-in doesn’t get to inspect and block the request, this means attackers would have access to all Docker Engine commands, including the ability to create privileged containers with root access.

Usually the most serious Docker vulnerabilities are those that allow attackers to escape from inside containers, but this flaw happens before the container is even created so any in-container monitoring tools would not catch the exploit attempt. Administrators can, however, route API requests through a reverse proxy that blocks all requests over 512KB for example, as a temporary mitigation.

Exposed Docker API interfaces are constantly targeted by botnets and attackers to hijack cloud instances and servers especially since Docker is used in over 90% of enterprise environments worldwide.

The Cyera researchers recommend searching daemon logs for signs of potential exploitation by using journalctl -u docker | grep “Request body is larger than”. They also advise reviewing which automated systems have Docker API access and prioritizing hosts with access to production credentials or regulated data for immediate patching.