Docker Engine crafted image denial of service (CVE-2021-21285)

Docker Engine versions prior to 20.10.3 contain a denial-of-service vulnerability — tracked as CVE-2021-21285 — that lets an attacker crash the Docker daemon simply by getting a victim to pull or load a specially crafted container image. No privileged access, no code execution primitive, and no interaction beyond a routine docker pull are required. The image manifest itself is the weapon: malformed or oversized layer/manifest metadata triggers an unhandled panic inside dockerd, taking down every container the daemon manages on that host until an operator manually restarts the service.

For teams that pull base images from public registries, run CI runners that build from third-party Dockerfiles, or accept customer-submitted container images in a multi-tenant platform, this is a meaningfully dangerous bug class: a single hostile image can knock an entire node offline, and the same weakness has recurred across several Moby/Docker advisories because container image parsing sits directly on the trust boundary between "content we didn't write" and "a process running as root."

What's affected

CVE-2021-21285 lives in Moby, the open-source engine that underpins Docker Engine, Docker Desktop, and a number of downstream container platforms. The vulnerable code path is in the image-pull/manifest-processing logic that Docker Engine uses whenever it retrieves an image — whether from Docker Hub, a private registry, or a local tarball loaded with docker load.

Affected:

• Docker Engine (Moby) prior to 20.10.3
• Docker Desktop builds that bundle a pre-20.10.3 engine
• Any downstream distribution or managed container service that vendors an unpatched Moby release

Not directly affected:

• Kubernetes control-plane components themselves (the issue is in the engine/runtime layer, not the orchestrator), though any node whose container runtime is Docker Engine inherits the exposure
• Deployments that have already upgraded to Docker Engine 20.10.3 or later

The fix landed in the same February 2021 security release that also addressed CVE-2021-21284 (an unsafe default permission issue affecting --userns-remap deployments), so environments patching for one should confirm they picked up both.

Because the trigger is "the daemon processes an image you told it to pull," exposure isn't limited to intentionally malicious actors. Compromised base images, tampered registry mirrors, typosquatted image names, or a poisoned CI cache can all deliver the crafted manifest just as effectively as a deliberate attack — which is why this class of bug matters even for organizations that believe they only run "trusted" images.

Severity, exploitability, and exposure

Public advisories for this vulnerability class assign it a Medium severity, with NVD scoring in the 5.x range on CVSS v3.1 — reflecting a low-complexity, no-privilege-required trigger that yields availability impact only (no confidentiality or integrity loss from this bug alone). That "availability-only" ceiling is precisely why it doesn't score Critical despite being trivially triggerable: an attacker can knock a node offline, but CVE-2021-21285 by itself doesn't hand over a shell, container escape, or data exfiltration path.

A few exploitability notes worth internalizing:

• EPSS is low. Exploit Prediction Scoring System data for this CVE sits near the bottom of the distribution, consistent with most container-runtime DoS bugs: there's no financial or persistence incentive for mass exploitation, and it requires convincing a target to pull a specific image rather than remotely reaching an exposed service.
• Not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. No confirmed in-the-wild exploitation has been publicly attributed to this CVE.
• The real risk is operational, not headline-grabbing. Low EPSS doesn't mean low relevance — it means the exploit path is niche (registry-supply-chain and CI/build-pipeline scenarios) rather than internet-scanned. Teams with public image ecosystems, shared build agents, or multi-tenant image ingestion are the ones who should weight this above its raw score.

The practical risk calculus differs sharply by environment. A single-tenant internal platform pulling only from a locked-down internal registry has narrow exposure. A CI/CD fleet that builds arbitrary developer-submitted Dockerfiles, or a platform that lets customers upload container images, has a wide, repeatable blast radius — every crafted image submission is a potential denial-of-service attempt against shared infrastructure.

Timeline

• Late 2020 / early 2021 — Vulnerability identified in Moby's image manifest handling and reported through Docker's responsible disclosure process.
• February 2021 — Docker and the Moby maintainers prepare a coordinated fix alongside the related permissions issue (CVE-2021-21284).
• February 24, 2021 — Docker Engine 20.10.3 ships publicly, resolving CVE-2021-21285 and CVE-2021-21284 as part of a bundled security release.
• February 2021 — CVE-2021-21285 is published via the GitHub Security Advisory database for the moby/moby repository and mirrored to NVD.
• Ongoing — Downstream distributions, managed Kubernetes services, and Docker Desktop pull the fix into their own release trains on staggered schedules — meaning "the CVE has a patch" and "your fleet is patched" are two different facts worth verifying independently.

Remediation

1. Upgrade Docker Engine to 20.10.3 or later. This is the definitive fix. Check docker version --format '{{.Server.Version}}' across every host, build runner, and Kubernetes node using Docker as the container runtime — not just your production cluster.
2. Update Docker Desktop to a version that bundles the patched engine if developers pull or build images locally; a laptop running a stale engine is still a valid attack surface for a poisoned dependency.
3. Audit downstream and managed platforms. If you consume a managed Kubernetes offering, CI SaaS, or container-as-a-service product, confirm with the vendor which Moby version underlies their runtime — the CVE being "fixed upstream" doesn't guarantee your provider has rolled it out.
4. Constrain what can be pulled. Enforce registry allow-lists, enable Docker Content Trust / image signing verification, and block ad-hoc pulls of unscanned public images in CI and production namespaces alike. The fewer arbitrary manifests your daemon parses, the smaller this bug's practical reach.
5. Isolate blast radius on shared build infrastructure. For CI runners or multi-tenant image-build services that must process untrusted Dockerfiles by design, run builds in ephemeral, single-use VMs or sandboxed runners rather than a long-lived shared daemon, so a crashed engine only takes down one job rather than the whole fleet.
6. Add runtime health monitoring for daemon crash-loops. A sudden restart pattern on dockerd correlated with a recent image pull is a strong operational signal worth alerting on, independent of whether it's this CVE or a future variant of the same bug class.
7. Re-verify after patching. Version-check alone can be misleading if packages were partially upgraded or a base image was rebuilt from a cached, outdated layer — confirm the running daemon binary, not just the installed package metadata.

How Safeguard Helps

Point patches for engine-level CVEs like this one are necessary but easy to lose track of across hundreds of hosts, CI runners, and container images — which is exactly the gap Safeguard is built to close. Our platform ingests or generates SBOMs across your build pipeline and running fleet, so you get a single, continuously updated inventory of exactly which nodes and images still run a pre-20.10.3 Docker Engine, instead of relying on tribal knowledge or a spreadsheet. Griffin AI then applies reachability analysis to this CVE class — distinguishing hosts where the vulnerable image-pull path is actually exercised (e.g., CI runners building untrusted Dockerfiles, multi-tenant image ingestion) from hosts pulling only from a locked-down internal registry, so your team patches the genuinely exposed systems first rather than triaging blind. Where the fix is a straightforward version bump — updating a base image tag, a runtime version pin in infrastructure-as-code, or a CI runner image — Safeguard can open an auto-fix pull request with the remediation pre-staged, cutting the time from "advisory published" to "fix merged" from days to minutes. The result is fewer denial-of-service surprises from your container supply chain, and a defensible, evidence-backed answer the next time an auditor or customer asks how quickly you close out engine-level CVEs like CVE-2021-21285.