Docker authorization plugins can approve an incomplete request

An authorization decision is only as complete as the request presented to the policy engine. If the daemon executes a body that the policy engine never inspected, an approval can authorize something different from what the policy evaluated. Docker's newly disclosed authorization-plugin vulnerability is a failure in that relationship between request processing and policy input.

The Moby advisory for CVE-2024-41110 describes specially crafted API requests that cause the engine to omit a request or response body when consulting an authorization plugin. A plugin that depends on the omitted content can allow an operation it would otherwise deny. The problem affects installations that use those plugins to make access-control decisions.

Docker's repeatable images are useful to me because they make application packaging explicit. Access to the engine that creates and starts those images has a different security role. A policy plugin needs to see the parts of an API operation that its policy actually constrains, including body content when that content determines the operation's permissions.

The lost fix predates the affected release branches

Docker's July 23 disclosure traces the issue to an earlier security repair. The original problem was discovered in 2018 and fixed in Engine 18.09.1 in January 2019. The fix did not carry forward into subsequent major versions, leaving a regression in the later release lines.

That history is more specific than a new weakness in a newly added authorization feature. The project had already identified relevant request-handling errors and corrected them. The failure was preserving those corrections across release history, so a version newer than the original fixed release could still contain the earlier behavior.

The advisory says the regression was identified in April 2024, with patches released on July 23. It identifies Docker CE 27.1.1 as containing a fix and records patch merges into multiple release branches. A patch in a branch and a packaged release remain distinct facts, so an installed version needs its own confirmed coverage.

The affected population also has explicit exceptions. The Moby advisory excludes Docker EE 19.03.x and all versions of Mirantis Container Runtime. Broadly describing every engine with a newer version number as vulnerable would erase those product distinctions and misstate the source's scope.

Body framing changes the policy input

The disclosure describes a request with Content-Length set to zero causing the daemon to forward no body to the plugin. The consequence depends on a mismatch between the content available for authorization and the operation processed by the engine. An empty policy input can therefore be significant even when the plugin itself receives and answers its normal authorization call.

The original fix helps explain that mismatch. Previously, the code sent an eligible body only when the request's content length was positive and below the maximum body size. Its replacement also recognized chunked transfer encoding, where a positive content length is not the right prerequisite for reading the message content.

Its helper examined both the transfer-encoding header and Go's parsed transfer-encoding values. The patch comment states that chunked encoding takes precedence over content length. The body-forwarding condition therefore needed to account for how the HTTP stack interpreted the request, rather than treating one length field as sufficient evidence of an empty body.

A follow-up correction used case-insensitive comparisons for identifying chunked encoding. That detail belongs to parsing the request's representation. A policy decision must not depend on a capitalization difference that the execution path treats as equivalent.

The general failure is easy to miss when a system logs that authorization ran successfully. The plugin can be called and return an approval while still lacking information it needs. Verifying invocation is therefore a weaker property than verifying that the input describes the operation eventually executed.

An authorization test can express the difference without depending on a particular production policy. Choose an operation that a body-sensitive policy rejects, submit equivalent content through the relevant HTTP representations, and require the same rejection. The assertion concerns the final decision and the content observed by the plugin. A test that checks only whether the plugin was called could pass under the vulnerable behavior, because omission of the body does not necessarily prevent that call. The historical patches provide concrete representations for constructing that comparison.

Endpoint classification also controls body visibility

The historical repair includes another relevant decision about when a body is forwarded. Authentication endpoints are treated specially, so the helper that classifies an endpoint influences what the authorization plugin receives. The patch changes that helper to parse the URL and classify its path.

The tests include a request whose query value ends in /auth but whose actual path is another endpoint. A string suffix check could mistake that representation for an authentication endpoint and suppress the body. Parsing the URL separates the path being classified from text in its query.

Other cases cover versioned authentication paths, authentication subpaths, and unrelated paths containing an auth component. The follow-up patch adjusts classification for URLs whose scheme and hostname are removed by parsing. Its tests include both absolute URLs and forms without a scheme.

These cases explain why the vulnerability's references contain both body framing and path validation work. Each decision affects whether the plugin sees content. Correctly reading a body is insufficient if the endpoint classifier wrongly decides that the body must be excluded before that reading occurs.

I find those historical tests more informative than a generic instruction to validate input. They name representations that can make policy and execution disagree. The useful invariant is that a change in representation must not suppress the facts on which the authorization decision depends.

Exposure depends on the plugin's policy

Moby identifies users who rely on authorization plugins that introspect request or response bodies as potentially impacted. That requirement matters. An installation without an authorization plugin does not gain an authorization bypass through a policy it never configured.

The plugin's behavior on incomplete input also matters. A policy that accepts a request when body information is absent may approve an operation it would reject after inspecting the body. Docker's disclosure specifically draws attention to plugins that do not deny by default in that circumstance.

This does not mean that denying every bodyless request is a universal policy. Some API operations legitimately have no relevant body. The policy needs to distinguish those operations from ones whose permissions depend on fields that must be present for inspection. The advisory establishes a bypass condition, not a complete replacement policy for every plugin.

Access to the Docker API is another prerequisite. The issue does not describe an arbitrary remote attacker sending requests to a daemon that is unreachable to them. It concerns clients that can submit engine API operations and rely on a plugin to limit which operations the daemon will permit.

Default access and constrained access are different models

Docker's disclosure describes default daemon authorization as all-or-nothing. Authorization plugins supply more selective controls using the authenticated identity and command context. A bypass is particularly relevant where a deployment has deliberately granted API connectivity while relying on those additional controls to reject dangerous operations.

Removing a plugin in such a deployment would also remove the selective control it supplied. The practical meaning of the advisory's mitigation is therefore tied to restricting API access to trusted parties. Merely deleting the policy component while preserving the same untrusted access does not preserve the intended permissions.

The Desktop discussion has narrower scope. Docker says default Desktop configurations do not include authorization plugins. Exploitation there also requires access to the Docker API, generally local access unless the daemon has been exposed over TCP. The disclosure describes escalation within the Desktop virtual machine rather than establishing escape to the underlying host.

Those qualifications should remain attached to the vulnerability description. An affected engine component inside a product does not prove that the product's default configuration exposes the vulnerable policy workflow. Conversely, a production installation using body-sensitive plugins has made those plugins part of its access-control enforcement.

The repair restores the request interpretation needed by that enforcement. The body presented to the plugin must correspond to the content the engine will process, and endpoint classification must not hide that content because unrelated URL text resembles an exempt path. Those are concrete conditions that can be exercised across release branches with the historical framing and path cases.