Docker Engine AuthZ Plugin Bypass: Incomplete Fix for CVE-2024-41110 Exploitable Again (CVE-2026-34040)

A vulnerability CVE-2026-34040 (CVSS 8.8) has been disclosed in Moby, the container engine behind Docker, that allows bypassing Authorization Plugins (AuthZ). The disclosure date is March 30, 2026. The patched version is 29.3.1; all prior versions are affected.

This vulnerability is a regression of CVE-2024-41110 (CVSS 10.0), which was fixed in July 2024. The earlier fix addressed one end (zero bytes) but left the other end (bodies exceeding 1MB) wide open.

What Are AuthZ Plugins?

By default, the Docker daemon processes API requests from connected clients with minimal restrictions. In enterprise or multi-tenant environments where fine-grained control over “which user can call which API” is needed, AuthZ plugins serve that purpose.

When the Docker daemon receives an API request, it forwards the request contents (headers + body) to the plugin before execution. The plugin returns an allow or deny decision. The plugin can inspect the request body — for example, the image name or privileged flag during container creation — to make its decision.

graph TD
    A[Docker Client] -->|API Request| B[Docker Daemon]
    B -->|Forward Request| C[AuthZ Plugin]
    C -->|Allow or Deny| B
    B -->|If Allowed| D[Execute Container Operation]
    B -->|If Denied| E[403 Forbidden]

CVE-2024-41110: The “Zero-Length” Bypass

To understand the current issue, we need to look at the predecessor CVE-2024-41110 first.

A bug allowing AuthZ plugin bypass via Content-Length: 0 API requests was originally fixed in Docker Engine v18.09.1 (January 2019). However, that fix was not carried forward to v19.03 and later, so the bug resurfaced.

The technical core was the condition r.ContentLength > 0. When Content-Length is zero, this evaluates to false, and the body is not forwarded to the plugin. The plugin sees an empty-body request and allows it, but the daemon reads and processes the actual request body.

POST /v1.45/containers/create HTTP/1.1
Content-Type: application/json
Content-Length: 0

{"Image":"ubuntu","HostConfig":{"Privileged":true}}

The AuthZ plugin evaluates this as “a POST request with an empty body” and cannot detect the intent to create a privileged container. CVE-2024-41110 fixed this lower-bound (zero-byte) issue, with patches shipped as v23.0.15, v26.1.5, and v27.1.1 in July 2024.

CVE-2026-34040: The “Upper-Bound” Bypass

The fix for CVE-2024-41110 only addressed the zero-byte case. CVE-2026-34040 exploits the overlooked upper bound.

When an API request body exceeds 1MB, Docker’s middleware silently truncates the body before forwarding it to the plugin. However, the daemon itself processes the complete, untruncated request.

graph TD
    A[Attacker] -->|Send API request exceeding 1MB| B[Docker Daemon]
    B -->|Middleware truncates body| C[AuthZ Plugin]
    C -->|Evaluates truncated small body| D{"Authorization Decision"}
    D -->|"Looks empty, allow"| E[Return to Daemon]
    B -->|Processes full original request| F[Privileged container creation, etc.]
    F --> G[Host filesystem access]
    F --> H[Cloud credentials / SSH key theft]
    F --> I[Kubernetes config file read]

An attacker only needs to pad the request to exceed the 1MB threshold. The attack chain complexity is minimal — no race conditions or multi-stage chains required. eSecurity Planet noted that “it completes in a single HTTP request and is difficult to detect in real environments.”

The CVSS vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (GitHub score: 8.8). The Scope (S) is “Changed (C)” because the impact crosses the container boundary to affect the host OS.

Conditions for This Vulnerability to Apply

The GitHub advisory (GHSA-x744-4wpc-v9h2) states it clearly: “If you are not using AuthZ plugins, you are not affected.”

The impact is limited to configurations where an AuthZ plugin is deployed and the plugin makes access control decisions based on request body content. Vanilla Docker environments, or those protected solely by TLS/mTLS without AuthZ plugins, are not affected.

Version Matrix

Docker Engine Version	Status
29.3.1 and above	Patched
Below 29.3.1 (all versions)	Affected

The fix commit is e89edb19ad7de0407a5d31e3111cb01aa10b5a38 (moby/moby repository).

A Long Bug History

This vulnerability lineage runs deep.

Year	Event
2018–2019	First AuthZ bypass discovered and fixed (v18.09.1)
2019 onwards	Fix not carried forward to v19.03+, regression occurs
July 2024	Rediscovered as CVE-2024-41110, patched in v27.1.1 etc.
March 2026	Upper-bound bypass discovered as CVE-2026-34040, patched in v29.3.1

According to eSecurity Planet, this vulnerability class has persisted for roughly 10 years counting from Docker Engine 1.10. A bug that was “thought to be fully fixed” turned out to be only half-fixed.

Mitigation

If you’re using AuthZ plugins, upgrade Docker Engine to 29.3.1 or later. That’s the top priority.

For environments where immediate upgrade is difficult, the official advisory lists these interim measures:

Do not rely on AuthZ plugins for decisions based on request body content
Restrict Docker daemon API access to trusted clients only (principle of least privilege)
Run Docker in rootless mode (reduces impact scope on the host)

After upgrading, verify that authorization policies are working as expected by testing with actual API requests. AuthZ plugin behavior rarely changes across patch versions, but it’s worth validating policy file compatibility once.

Do You Actually Need Docker?

This vulnerability is specific to Docker Engine’s AuthZ plugin mechanism. For workloads where Docker is not a strict requirement, alternative runtimes can architecturally eliminate this entire vulnerability class.

Runtime	Characteristics	AuthZ-Related Risk
Podman	Daemonless, rootless by default, Docker CLI compatible	No central daemon means the AuthZ bypass attack surface doesn’t exist
nerdctl + containerd	Docker-compatible CLI that operates containerd directly	No AuthZ plugin mechanism. Access control via containerd namespaces and cgroups
Kata Containers	Isolates containers in lightweight VMs	Strong isolation via VM boundaries. Defense at a layer separate from runtime API authorization
gVisor (runsc)	Application kernel mediates system calls	Blocks direct host kernel access. Significantly reduces the impact scope of privileged containers

Podman in particular is largely CLI-compatible with Docker — in many cases, replacing the docker command with podman just works. Since there is no daemon process at all, the threat model of API attacks via the daemon socket simply disappears. Red Hat distributions (RHEL, Fedora) have adopted Podman as the default container tooling in place of Docker.

That said, Docker Compose ecosystem compatibility, build cache behavior, and other areas are not 100% identical. Migration costs can be significant for CI/CD pipelines using Docker-in-Docker configurations or those dependent on Docker Swarm.

The decision criterion is straightforward: if you need fine-grained access control via AuthZ plugins, update Docker Engine and keep using it. If you don’t, and rootless execution with a daemonless architecture better fits your security requirements, migrating to Podman is worth considering.