Docker Engine remap-root UID mapping vulnerability (CVE-2021-21284)

A privilege escalation vulnerability in Docker Engine's user namespace remapping feature, tracked as CVE-2021-21284, allowed a process with remapped-root access inside a container to write files that Docker's daemon would later interpret with real host-root privileges. When --userns-remap (also called "remap-root") is enabled, Docker is supposed to translate the container's root user to an unprivileged UID/GID range on the host — a core defense-in-depth control for multi-tenant and hardened Docker deployments. The flaw undermined that boundary: because the daemon set ownership of sensitive data-root directories (including container and checkpoint directories under /var/lib/docker/<remapping>) using the remapped root identity rather than the daemon's own identity, a remapped "root" user with filesystem access could modify files that Docker would subsequently trust and execute with full host privileges — effectively converting a namespace-contained root into the real thing.

Why this mattered

User namespace remapping exists specifically to blunt the impact of container-to-host breakouts. It is one of the primary mitigations organizations reach for when they cannot run rootless Docker outright but still want to reduce the blast radius of a compromised or malicious container. CVE-2021-21284 is notable precisely because it attacked the control meant to contain root-equivalent compromise, not a peripheral feature. An attacker who already had remapped-root-level access to the host filesystem — for example, through a mounted volume, a misconfigured bind mount, or another primitive that exposed /var/lib/docker paths — could leverage this gap to escalate from "root inside a remapped namespace" to "root on the host," defeating the isolation guarantee that teams had specifically enabled userns-remap to get.

Affected versions and components

• Component: Docker Engine / Moby (docker-ce), specifically the --userns-remap (user namespace remapping) feature.
• Affected versions: Docker Engine prior to 19.03.15 and prior to 20.10.3.
• Patched versions: 19.03.15 and 20.10.3 and later.
• Prerequisite: The vulnerability only applies to daemons that have explicitly enabled userns-remap; hosts running Docker with default settings (no remapping configured) are not affected by this specific issue.
• Downstream exposure: Because Moby is embedded in numerous products, several vendors shipped their own advisories referencing the same root cause, including Bottlerocket OS (patched in 1.0.6) and various Linux distribution and appliance vendors that bundle Docker Engine.

CVSS, EPSS, and KEV context

• CVSS v3.1 Base Score: 6.8 (Medium), vector CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N. The vector reflects an adjacent attack vector, low attack complexity, low privileges required, no user interaction, a scope change (the impact crosses the namespace boundary into the host), and a high integrity impact with no confidentiality or availability impact.
• CWE classification: CWE-22, Improper Limitation of a Pathname to a Restricted Directory ("path traversal"), reflecting how the remapped-root identity was able to reach and modify files outside its intended data-root confinement.
• EPSS: Historically scored extremely low (around 0.02% probability of exploitation in the next 30 days), reflecting the absence of observed in-the-wild exploitation and the narrow prerequisite (remap-root must already be enabled and the attacker must already have namespace-root access).
• CISA KEV catalog: CVE-2021-21284 is not listed in CISA's Known Exploited Vulnerabilities catalog. There is no public evidence of active exploitation.

This is a useful reminder that CVSS severity, EPSS likelihood, and KEV status can diverge meaningfully: a Medium-severity, low-EPSS, non-KEV CVE can still represent a real and worth-fixing gap in a security control that organizations depend on for containment, particularly in regulated or multi-tenant environments where "root inside the namespace" is assumed to be a hard boundary rather than a soft one.

Timeline

• Discovery: Reported by security researcher Alex Chapman, with responsible disclosure coordinated by Zac Ellis to Docker's security team (security@docker.com).
• February 2, 2021: CVE-2021-21284 published to NVD alongside the coordinated Moby/Docker security advisory (GHSA-7452-xqpj-6rpc), issued together with related fixes such as CVE-2021-21285 (a separate image-extraction issue) as part of the same Docker Engine 19.03.15 / 20.10.3 security release.
• Fix: The patch changed how the daemon establishes ownership of its data-root directories — moving from daemon.idMapping.RootPair() (the remapped root identity) to idtools.CurrentIdentity() (the daemon's actual host identity) — and tightened directory permissions from 0700 to 0701, closing the path that let a remapped root user write files the daemon would trust.
• Downstream propagation: Vendors bundling Moby, including Bottlerocket OS, published their own fixes in the following weeks (e.g., Bottlerocket 1.0.6, advisory published March 2, 2021).

Remediation steps

1. Patch Docker Engine immediately if you use userns-remap. Upgrade to Docker Engine 19.03.15, 20.10.3, or any later release. If you are not using user namespace remapping, this specific CVE does not apply to you, but you should still be current on Docker Engine patches generally.
2. Inventory where userns-remap is enabled. Check /etc/docker/daemon.json for a userns-remap key, and audit fleet-wide configuration management (Ansible, Chef, Terraform, golden AMIs) for hosts that enable it. Don't assume — verify across every environment where hardened Docker configurations were deployed.
3. Restrict filesystem access to /var/lib/docker. Regardless of patch status, ensure containers cannot bind-mount or otherwise reach the Docker data-root directory from inside a remapped namespace. This is a general best practice that also reduces exposure to similar classes of issues.
4. Rebuild and redeploy affected daemons rather than live-patching in place where your operational model allows it — image-based infrastructure reduces the chance that a compromised remapped-root identity persists through an in-place upgrade.
5. Re-validate namespace isolation post-patch. After upgrading, confirm that files written from within a remapped-root context are still owned by the mapped UID/GID range on the host, not by the real root UID, using ls -n against /var/lib/docker/<remap-name>.<remap-name>/.
6. Review related, co-disclosed CVEs from the same advisory batch (e.g., CVE-2021-21285) since environments running pre-19.03.15/pre-20.10.3 Docker Engine are very likely exposed to more than just this one issue.
7. Layer in rootless Docker or gVisor/Kata where feasible. userns-remap is a mitigation, not a sandbox; for genuinely hostile multi-tenant workloads, pair it with stronger isolation primitives rather than treating remap-root alone as sufficient.

How Safeguard Helps

Legacy Docker Engine deployments running userns-remap are exactly the kind of quietly-drifted infrastructure that CVE backlogs are made of — easy to enable years ago, easy to forget about, easy to miss in a patch cycle. Safeguard's Griffin AI continuously correlates fleet-wide configuration and container runtime data with CVE feeds like this one, flagging hosts where userns-remap is active on an unpatched Docker Engine version before it becomes an audit finding. Our reachability analysis goes beyond "is the vulnerable package present" to determine whether the vulnerable code path — the daemon's data-root ownership logic — is actually reachable given your configuration, cutting through noise so teams aren't chasing every Docker CVE with equal urgency. Safeguard's SBOM generation and ingestion pipeline captures the exact Docker Engine version across your container hosts and CI runners, giving you a queryable inventory the moment a new Moby advisory drops. And where a fix is available, Safeguard can open an auto-fix pull request against your infrastructure-as-code or image-build pipelines, pinning the patched Docker Engine version so remediation ships in minutes rather than surviving another sprint on the backlog.