CVE-2024-41110: Docker Engine AuthZ Body Bypass Patch Guide

  • Thread Author
A regression in Moby’s authorization path has resurfaced a long‑standing risk: CVE‑2024‑41110 lets the Docker Engine forward API calls to AuthZ plugins without the request body when a client sets a zero Content‑Length, giving an attacker the chance to bypass authorization checks that rely on the body. The bug is a classic regression — a fix applied in 2019 was not carried forward into later release branches — and patches were issued in July 2024. For any environment that uses authorization plugins (AuthZ) to make access decisions, this vulnerability can permit unauthorized actions and privilege escalation unless mitigated or patched.

Background / Overview​

Authorization plugins (AuthZ) are a common way to extend Docker Engine with custom access controls that inspect API request metadata and, crucially, request/response bodies before allowing an action. In 2018 a flaw was discovered where specially crafted API requests could cause the daemon to call AuthZ plugins without forwarding the body; that issue was fixed in Docker Engine v18.09.1 (January 2019). Unfortunately the same bug reappeared — a regression — in later branches and was tracked as CVE‑2024‑41110 after rediscovery in early 2024. Docker and the Moby maintainers published advisories and merged fixes across release branches in July 2024.
The practical risk profile of CVE‑2024‑41110 depends mostly on two operational facts: (1) whether you use AuthZ plugins that inspect request bodies to make allow/deny decisions, and (2) whether an attacker can send requests to the Docker daemon (locally via the Unix socket or remotely where the API is exposed over TCP). When both conditions are true, the vulnerability enables bypasses that may permit starting privileged containers, reading or writing secrets, or any action the plugin would otherwise deny when given the full request body. (nvd.nist.gov)
I also reviewed the uploaded forum and monitoring excerpts supplied in the conversation to confirm there was community discussion and alerting activity around the advisory and patches.

How the bug works — technical deep dive​

The root cause: body forwarding mismatch​

At a high level, the Docker daemon mediates API requests from clients and, when enabled, consults AuthZ plugins before executing an action. The daemon must forward both headers and the body (when present) so the plugin can make an accurate decision. CVE‑2024‑41110 arises when a client submits a request with a zero Content‑Length header while actually including a non‑empty body (or when internal code treats Content‑Length==0 as “no body”) and the daemon ends up invoking the plugin without sending the body. If the plugin’s policy only denies actions based on the contents of that body, the plugin may approve the request incorrectly.
Practically, exploitation looks like this:
  • The attacker crafts an HTTP API request to a sensitive endpoint (for example, /containers/create or /containers/{id}/start) where the action is only blocked when the body contains a sensitive flag (e.g., "Privileged": true or environment variables/secrets).
  • The request header sets Content‑Length: 0 while a non‑empty payload is included anyway (or another edge condition triggers body omission).
  • The Docker daemon calls the AuthZ plugin with headers but without the body.
  • The plugin—unable to see the disallowed flag—returns allow.
  • The daemon proceeds with the operation, performing an action the plugin would have rejected had it seen the body.
Multiple vulnerability trackers and advisories describe the same vector: a zero‑length regression that strips the body before plugin evaluation. The exact code paths implicated include the Moby authorization package (symbols such as Ctx.AuthZRequest, Ctx.AuthZResponse and sendBody were referenced in the vulnerability metadata). Fixes were applied in several commits across release branches to ensure the body is forwarded correctly to the plugin.

Why the regression happened​

This is important context for maintainers: the bug is not a new design flaw but a regression — a previously fixed issue that was not propagated to later major release branches. Regression bugs like this typically occur when a fix is applied to a single branch (for example, 18.09) and the patch is later not backported or re‑implemented in parallel branches (19.x, 20.x, etc.). In a large, multi‑branch open source project with many release lines, a small change in request handling can slip through code evolution and testing gaps, especially around nuanced HTTP contract behavior. Docker/Moby maintainers recognized this pattern, tracked the regression, and merged patches into the active branches.

Affected versions and patch timeline​

  • Affected release ranges include a wide swath of Docker Engine versions present in many distributions and Docker Desktop releases; the advisory enumerated the vulnerable ranges as versions up to particular release boundaries in the 19.x, 20.x, 23.x, 24.x, 25.x, 26.x and 27.x lines. The GitHub advisory and Docker’s blog list the exact version thresholds and the patched release boundaries.
  • Docker and Moby issued patches and merged fixes across branches in July 2024; docker‑ce v27.1.1 was cited as containing the comprehensive fixes and patches were merged into master and multiple release branches. Package managers and vendors backporting Docker into distributions also released updates; Ubuntu and other distributors subsequently issued fixes tied to their packaging.
  • Docker Desktop: desktop releases up to v4.32.0 included affected Engine versions; Docker Desktop 4.33.0 and later bundles patched Engine versions. For production and server installations, operators must follow their platform vendor’s packages (for example, docker.io packages in Debian/Ubuntu or vendor images in managed clouds) and apply vendor updates promptly.

Exploitation scenarios — who should worry most​

Not all Docker users are equally exposed. The vulnerability is most dangerous when three conditions overlap:
  • The deployment uses AuthZ plugins that rely on the request or response body to make decisions.
  • The attacker can send requests to the Docker daemon (local Unix socket access or a remotely exposed daemon).
  • The environment includes sensitive operations controllable via the Engine API (creating privileged containers, accessing mounted secrets or sockets, enabling privileged mounts, or performing host‑level operations).
High‑risk real‑world scenarios include:
  • Multi‑tenant CI runners and shared developer workstations where multiple untrusted users may have socket access.
  • Servers with Docker’s API bound to a TCP port and insufficiently protected by TLS/firewalls.
  • Managed services or automation systems that rely on AuthZ plugins for fine‑grained policy enforcement (for example, restricting creation of privileged containers or controlling secret access).
  • Containers or control planes that expose the Docker socket inside a container (docker‑in‑docker or bind‑mounted /var/run/docker.sock), allowing lower‑privilege workloads to reach the host daemon.
An important operational note: when the Docker API is only accessible to a trusted, well‑controlled local admin, the likelihood of remote exploitation is lower; however, local privilege escalation remains a concern if an attacker already has access to a build agent or misconfigured container with access to the socket. Docker’s advisory explicitly highlights that exploitation typically requires access to the daemon (e.g., local users or insecure TCP exposure).

Detection, hunting and forensics​

If you rely on AuthZ plugins, or run Docker instances that might be affected, hunt for the following indicators:
  • Audit logs or web server logs showing Engine API requests with header Content‑Length: 0 directed at privileged endpoints (/containers/create, /containers/{id}/start, /secrets, /volumes, /exec).
  • Requests where the logged body length does not match the Content‑Length header, or where a plugin receives requests but has no body due to truncation.
  • Unexpected container lifecycle events: creation of containers with privileged flags, containers started with host mounts or device passthrough that would normally have been blocked by your AuthZ policy.
  • Sudden appearance of new images, newly created admin users in orchestration tooling, or evidence of lateral movement from CI runners or developer machines.
Short forensic checklist:
  • Preserve the Docker daemon logs and AuthZ plugin logs immediately.
  • Capture a timeline of API calls with full headers and bodies if available (some logging systems capture both; otherwise, review network captures and syslog/auditd).
  • Extract docker events and container histories (docker events, docker ps -a, docker inspect) and preserve image IDs and container filesystem snapshots.
  • Verify if any containers were created with privileged mode, host networking, or with mounts of /var/run/docker.sock or host volumes.
  • If a breach is suspected, assume credential compromise and rotate service account secrets and CI tokens as appropriate.
Note: log collection and centralization (SIEM, cloud log pipelines) make this hunting significantly easier; team owners should create detection rules that flag mismatches between Content‑Length and actual request payload sizes and pre‑approved API clients.

Mitigations and remediation​

Immediate (0–48 hours)​

  • Patch first: Upgrade Docker Engine to a patched version (as listed in Docker’s advisory) as soon as possible. Docker documented which release tags include fixes and the GitHub advisory lists the patched release boundaries. Patching is the definitive remediation.
  • If you cannot patch immediately:
  • Disable AuthZ plugins. If your organization can temporarily disable authorization plugins without violating policy constraints, do so until you deploy a patched Engine. That removes the attack surface the vulnerability targets.
  • Restrict access to the Docker API. Ensure the Docker daemon socket is only accessible to trusted users and processes. Block any TCP exposure of the API with firewall rules and avoid binding the daemon to a public interface.
  • Isolate build runners and shared developer machines. Where possible, use ephemeral runners with no persistent socket exposure, avoid mounting /var/run/docker.sock into untrusted containers, and enforce least privilege for local user accounts.
  • Audit: Immediately search logs for suspicious zero Content‑Length requests and for unexpected privileged operations. If you have monitoring that can detect anomalous container starts or new images, increase scrutiny on those alerts.

Medium term (weeks)​

  • Apply vendor package updates for Docker provided by your OS or container platform (some distributions repackage engine versions). Confirm patched package versions with your distro vendor.
  • Harden CI/CD pipelines: remove unnecessary socket access inside pipeline jobs, adopt remote API proxies that perform additional authentication, and instrument pipelines to require signed or approved job definitions.
  • Consider limiting use of AuthZ plugins to cases where they are strictly necessary and ensure plugins are defensive by default (deny when unsure).

Long term (strategic)​

  • Replace or complement in‑process plugin checks with out‑of‑band policy enforcement where feasible (e.g., admission controllers in orchestrators that operate at a higher level and re‑evaluate full request contexts).
  • Adopt a layered defense model: rootless containers, strong host hardening, minimal set of users who can access /var/run/docker.sock, and runtime policy enforcement tools.
  • Improve CI pipeline isolation (use VMs rather than bind‑mounted sockets, or run each build in a fully ephemeral ephemeral environment that cannot reach the host daemon).

Developer and maintainer takeaways​

For maintainers and authors of AuthZ plugins, there are important lessons:
  • Never assume headers are honest — plugins should be defensive about missing bodies and deny by default or require explicit allowance for zero‑length path cases.
  • Add fuzzing and regression tests that assert behavior when clients set unusual headers (Content‑Length mismatch, chunked encodings, etc.). This bug was an example where a historical fix was not ported across branches; tests should live in shared test harnesses across branches to catch regressions.
  • Log clearly whenever a plugin invocation receives no body; logs are essential to detect misuse and are invaluable during investigations.
For platform engineers, require that any in‑process access control be paired with audit logs and out‑of‑band verification where possible. The incident underscores how a small HTTP contract nuance can defeat policy decisions if assumptions about the transport layer change.

Risk analysis and operational impact​

CVE‑2024‑41110 has a meaningful impact for organizations that depend on AuthZ plugins for fine‑grained policy enforcement. The advisory and several trackers score the vulnerability highly because a successful bypass can lead to elevated access and actions that change the system state (creating privileged containers, exposing host resources, reading secrets). That said, the real‑world exploitability depends heavily on access controls to the daemon:
  • If the Docker API is restricted to root/administrators with no untrusted local users and not bound to network interfaces, the practical risk is reduced but not eliminated (attacker must first gain an initial foothold).
  • If the API is exposed to developer workstations, remote CI runners, or misconfigured cloud VMs, the vulnerability becomes much easier to exploit.
  • There was no widely reported evidence at publication time of widespread active exploitation in the wild, and many vendor advisories described the base likelihood as low — but low likelihood does not equal low impact, and the vulnerability should be triaged as high priority in any environment using AuthZ plugins.

Practical detection and rule examples​

Security teams can implement the following detection heuristics in their logging and gateway pipelines:
  • Alert when a client issues a POST/PUT to container‑creation or start endpoints and Content‑Length == 0.
  • Compare application logs or plugin invocations: when the engine logs a plugin call with no body for an endpoint normally containing a JSON payload, escalate.
  • Monitor for newly created containers with: Privileged==true, HostNetwork==true, or with bind mounts that include sensitive host paths. Correlate these with any recent zero‑length requests.
Example SIEM rule (pseudocode):
  • Source: Docker API access logs
  • Condition: http.method in [POST, PUT, PATCH] AND http.headers.Content-Length == "0" AND http.path matches /containers|/secrets|/exec
  • Action: Alert + add to suspicious activity timeline.
Log enrichment that includes the invoking user/process and socket path can speed triage. Remember: logs must be immutable and retained for a period consistent with your regulatory and incident response needs.

Final recommendations — checklist​

  • Patch Docker Engine and Docker Desktop to the patched releases referenced in Docker’s advisory as your first priority.
  • If patching is delayed, disable AuthZ plugins and lock down daemon access immediately.
  • Hunt for suspicious zero‑length requests and unexpected privileged container lifecycle events; preserve logs and artifacts.
  • Harden CI/CD and developer machines: remove unnecessary socket exposure and avoid bind‑mounting /var/run/docker.sock into untrusted containers.
  • For plugin authors: adopt deny‑unless‑explicit policy behavior and add tests that simulate body omission and header mismatches.

Conclusion​

CVE‑2024‑41110 is a reminder that subtle protocol and transport assumptions can undo access controls. The vulnerability is a straightforward concept — an API body omitted during AuthZ evaluation — but the operational consequences are real for any deployment that uses authorization plugins and allows untrusted access to the Docker daemon. The fix exists and maintainers merged patches across branches in July 2024, but the remediation gap between discovery and patching, combined with the variety of Docker packaging across OS vendors and desktop bundles, means defenders must actively patch, mitigate, and hunt.
Treat this vulnerability as a high‑priority patch for environments using AuthZ plugins, and apply the mitigation checklist above: patch, restrict access, disable AuthZ if necessary, and hunt for indicators. For platform owners and plugin writers, add regression tests for unusual HTTP header/body combinations so a fix applied once does not reappear in another branch years later.
Source: MSRC Security Update Guide - Microsoft Security Response Center
 
Click to expand...
You must log in or register to reply here.