CVE-2026-34040: Authorization Bypass via Oversized Request Body in Moby (Docker Engine)

The Moby container framework (Docker Engine) provides an authorization plugin (AuthZ) architecture to enforce security policies on API requests. These plugins evaluate incoming requests before the Docker daemon processes them. Administrators use this mechanism to restrict actions such as mounting sensitive host directories, exposing privileged ports, or creating privileged containers.

CVE-2026-34040 is an authorization bypass vulnerability (CWE-288) affecting the AuthZ framework in Moby versions prior to 29.3.1. The flaw occurs when an attacker submits an API request with a body size exceeding an internal buffering threshold. The daemon forwards an empty body to the plugin for evaluation while retaining the original request payload for execution.

Because many AuthZ plugins default to an "allow" state when inspecting empty request bodies, the malicious request passes the authorization check. The Docker daemon then proceeds to execute the original, un-inspected request. This decoupling of the validation payload from the execution payload results in a complete bypass of the implemented security controls.

The vulnerability resides in the AuthZRequest function located in pkg/authorization/authz.go. To forward request data to external authorization plugins, the Moby daemon attempts to read and buffer the incoming request body using a function named drainBody.

The drainBody function relies on a buffered reader configured with a hardcoded maxBodySize limit of 1,048,576 bytes (1MB). When processing an incoming API request, the code calls bufReader.Peek(maxBodySize) to extract the body content. If the actual request body exceeds this 1MB limit, the Peek method returns an empty byte slice (nil) along with an error state.

The vulnerable implementation failed to properly handle this error state or enforce a fail-closed behavior. Instead of rejecting the oversized request or returning a severe error, the AuthZRequest logic continued execution and transmitted the nil body to the AuthZ plugin.

The AuthZ plugin receives the HTTP headers alongside an empty body. Lacking any restricted fields (such as HostConfig.Binds) to evaluate, the plugin authorizes the request. Following this approval, the Docker daemon reads the original incoming request stream, consuming the complete oversized payload and executing the restricted action.

The patch implemented in Moby version 29.3.1 (commit e89edb19ad7de0407a5d31e3111cb01aa10b5a38) addresses the parsing discrepancy by enforcing a strict fail-closed mechanism. The developers increased the maximum body size limit and modified the buffer inspection logic to detect and reject oversized requests explicitly.

In the vulnerable version, the daemon silently accepted the truncation. The patched version increases the maxBodySize threshold to 4MiB (4,194,304 bytes). Crucially, the code now utilizes a Peek operation specifically designed to check if the payload exceeds this new limit by inspecting maxBodySize + 1.

// Patched logic in pkg/authorization/authz.go
maxBodySize := 4194304 // 4MiB
 
// Attempt to peek one byte beyond the maximum allowed size
if _, err := bufBody.Peek(maxBodySize + 1); err == nil {
    // If the peek succeeds, the body is larger than the limit
    return fmt.Errorf("request body too large for authorization plugin: size exceeds %d bytes", maxBodySize)
}

By verifying the existence of data beyond the maximum boundary, the daemon reliably detects oversized payloads. If the limit is exceeded, the daemon immediately returns a hard error, rejecting the request before any interaction with the AuthZ plugin occurs. This strictly prevents the execution of unvalidated payloads.

Exploitation of CVE-2026-34040 requires an attacker to possess existing permissions to communicate with the Docker API. This access typically manifests as local access to the /var/run/docker.sock UNIX socket or network access to an exposed Docker TCP endpoint.

The attack relies on padding a malicious JSON payload with superfluous data to exceed the 1MB threshold. An attacker targets a restricted endpoint, such as the container creation API (POST /v1.41/containers/create). The payload includes the unauthorized configuration, such as a host bind mount targeting /etc/shadow, alongside an artificially inflated field.

{
  "Image": "alpine",
  "Cmd": ["cat", "/host/etc/shadow"],
  "HostConfig": {
    "Binds": ["/:/host"]
  },
  "Padding": "<insert 1.05MB of arbitrary characters here>"
}

Upon receiving this payload, the Docker daemon evaluates the request body size. Because the size exceeds the internal 1MB limit, the Peek function fails to extract the body. The daemon passes an empty payload to the AuthZ plugin, which approves the transaction. The daemon subsequently processes the full JSON structure, ignores the unknown Padding key, and creates the container with the privileged bind mount.

The primary impact of this vulnerability is unauthorized privilege escalation and complete host compromise. By bypassing the AuthZ plugin framework, an attacker can execute actions explicitly forbidden by the organization's security policy.

The vulnerability carries a CVSS v3.1 score of 8.8. The local attack vector indicates the attacker must reach the Docker API, but the resulting scope change reflects the ability to break container isolation. The impact on confidentiality, integrity, and availability is high, as the attacker can gain root-level access to the underlying host system.

This bypass affects numerous enterprise deployments, including environments running Docker Desktop, Docker Engine on Linux, and cloud infrastructure leveraging the Moby project. If administrators rely solely on AuthZ plugins to enforce multitenancy or restrict administrative actions, the isolation guarantees are completely negated.

Organizations must immediately upgrade Moby (Docker Engine) to version 29.3.1 or later to remediate this vulnerability. This update implements the necessary fail-closed validation logic and expands the buffer capacity to accommodate larger, legitimate requests.

If immediate patching is not technically feasible, administrators must restrict access to the Docker API socket. Only highly trusted users should possess permissions to interact with the Docker daemon. Network-exposed Docker APIs should be secured using mutual TLS (mTLS) and restricted via strict firewall rules.

As a defense-in-depth measure, administrators should verify that AuthZ plugins are not the sole mechanism enforcing container isolation. Implementing secondary controls, such as strict AppArmor profiles, Seccomp filtering, and user namespaces, limits the blast radius of unauthorized container creation even if the initial authorization boundary is bypassed.