A high‑severity flaw has been identified in Docker Engine that could allow attackers to circumvent authorization controls under certain conditions.
The issue, assigned CVE‑2026‑34040 with a CVSS score of 8.8, arises from an incomplete remediation of CVE‑2024‑41110, a critical Docker Engine vulnerability disclosed in July 2024.
According to Docker maintainers, a specially crafted API request can cause the Docker daemon to pass an authorization request to an AuthZ plugin without including the request body. Because some authorization plugins rely on inspecting the body to enforce access controls, this omission can result in unauthorized requests being mistakenly approved.
Docker warned that any environment depending on authorization plugins that analyze request bodies for security decisions could be affected.
The vulnerability was independently discovered and reported by multiple security researchers, including Asim Viladi Oglu Manizada, Cody, Oleh Konko, and Vladimir Tokarev. Docker addressed the issue in version 29.3.1 of Docker Engine.
Research published by Vladimir Tokarev of Cyera Research Labs explains that the original fix for CVE‑2024‑41110 failed to properly account for oversized HTTP request bodies. As a result, an attacker can exploit this weakness by sending a single padded HTTP request large enough to exceed plugin limits, allowing the request to bypass authorization checks entirely. This can lead to the creation of a privileged container with access to the host file system.
In a theoretical attack scenario, an adversary with Docker API access restricted by an AuthZ plugin could defeat those protections by inflating a container‑creation request beyond 1 MB. The oversized request is dropped before reaching the plugin, effectively neutralizing its enforcement.
“The plugin permits the request because it receives no data to evaluate,” Tokarev explained. “Meanwhile, the Docker daemon processes the full request and spins up a privileged container with root‑level access to the host, exposing AWS credentials, SSH keys, Kubernetes configurations, and other sensitive assets.” According to Tokarev, the technique impacts every AuthZ plugin currently in use.
The risk is further amplified by the use of artificial‑intelligence coding agents. An AI agent such as OpenClaw, operating within a Docker‑based sandbox, could be manipulated via prompt injection embedded in a carefully crafted GitHub repository. Executed as part of a routine developer workflow, the injected instructions could cause the agent to exploit CVE‑2026‑34040, bypass authorization checks, create a privileged container, and mount the host file system.
Once this level of access is achieved, attackers can harvest cloud credentials and use them to compromise cloud accounts, Kubernetes clusters, and even establish SSH access to production systems.
Cyera also noted that malicious repositories may not even be necessary. AI agents could independently infer the bypass technique while troubleshooting legitimate issues. For example, if an agent encounters access errors while attempting to read files such as a kubeconfig during a routine debugging task, it may generate a padded HTTP request on its own to overcome the restriction.
As Cyera explained, an AuthZ plugin may block a mount request, but an AI agent with Docker API access and an understanding of HTTP can trivially construct the bypass. The exploit does not require specialized tools, elevated privileges, or exploit code only a single oversized HTTP request. Any agent capable of reading Docker API documentation could reproduce it.
As interim mitigation measures, users are advised to avoid authorization plugins that depend on request body inspection, restrict Docker API access to trusted principals in line with least‑privilege practices, or operate Docker in rootless mode.
Tokarev emphasized that in rootless configurations, even a privileged container’s root user maps to an unprivileged user on the host. While this does not eliminate risk, it significantly reduces impact from full host takeover to compromise of a non‑privileged account. For systems that cannot fully adopt rootless mode, the userns-remap option offers a comparable level of user‑ID isolation.
Found this article interesting? Follow us on X(Twitter) ,Threads and FaceBook to read more exclusive content we post.
