CVE-2026-46680: containerd runAsNonRoot Bypass via Numeric User Parsing Flaw

Technical summary

The vulnerability exists in containerd's user parsing logic for the User directive in container images. Versions 1.7.x before 1.7.32, 2.0.x before 2.0.9, 2.2.x before 2.2.4, and 2.3.x before 2.3.1 fail to properly validate numeric UIDs that exceed 32-bit integer limits (2^31-1). When parsing fails, the runtime falls back to treating the value as a username rather than erroring out. A crafted image with a corresponding entry in /etc/passwd allows the numeric string to resolve to UID 0 (root), circumventing the runAsNonRoot enforcement mechanism. The root cause relates to improper input validation and fallback logic during user ID resolution (CWE-269: Improper Privilege Management).

Business impact

Organizations running Kubernetes with runAsNonRoot pod security policies face a critical control bypass. Containers intended to operate with dropped privileges can be forced to run as root, negating isolation and least-privilege protections. This is especially dangerous in multi-tenant environments or where workload sandboxing is relied upon for security. A compromised or malicious image supply chain can silently escalate container privileges, enabling lateral movement, data exfiltration, or host compromise. The impact depends on the container's capabilities and network access but could enable full cluster compromise if the container has privileged access or volume mounts to sensitive host paths.

Affected systems

containerd versions 1.7.x (before 1.7.32), 2.0.x (before 2.0.9), 2.2.x (before 2.2.4), and 2.3.x (before 2.3.1) are affected. Kubernetes clusters using these containerd versions are at risk, particularly those relying on runAsNonRoot enforcement. Docker Desktop and other container platforms that bundle or depend on containerd may be indirectly affected; verify your specific distribution's containerd version. Air-gapped or private registry deployments are not immune—attackers with image push access or via supply chain compromise can deploy malicious images.

Exploitability

Exploitation requires either the ability to push or modify a container image in a registry that the target environment trusts, or to compromise an upstream image source. The malicious image must be explicitly pulled and run by a user or Kubernetes controller. No network interaction or special privileges are needed at runtime; the attack is triggered simply by launching the container. The barrier to exploitation is relatively low for attackers with image supply chain access or those targeting environments with weak image validation controls. Kubernetes administrators who do not verify image signatures or origins are most at risk.

Remediation

Upgrade containerd to one of the patched versions: 1.7.32, 2.0.9, 2.2.4, or 2.3.1. For Kubernetes deployments, this typically means updating the containerd package on all nodes in your cluster. Verify compatibility with your Kubernetes version before rolling out updates. In addition, enforce image signature verification and admission controls (e.g., Kyverno, OPA/Gatekeeper, or native Pod Security Standards) to reject unsigned or untrusted images. Audit running pods to identify any that may have unexpectedly escalated to root privileges.

Patch guidance

1. Check your current containerd version: containerd --version. 2. Plan a maintenance window for node updates, as containerd updates typically require a daemon restart. 3. Upgrade using your package manager or distribution mechanism (e.g., apt/yum on Linux, Docker Desktop updates for Mac/Windows). 4. Verify the new version is running on all nodes: kubectl get nodes -o wide to confirm containerd version propagation. 5. Monitor container startup logs for any unexpected privilege elevation. 6. Test non-root pod enforcement with a test deployment before considering the migration complete. For organizations on extended support branches (e.g., 1.7.x), verify that your vendor or distribution has backported the fix.

Detection guidance

Monitor for containers that unexpectedly run as UID 0 despite runAsNonRoot policies. Check pod logs and kubelet audit logs for privilege mismatch warnings. Use runtime security tools (Falco, Tetragon) configured to detect UID mismatches between expected and actual container execution context. Review image pull logs for unexpected or untrusted image sources. Implement OPA/Gatekeeper rules to audit and block container User directives that are non-numeric or exceed safe integer bounds. If you have access to image scanning, flag images with suspicious numeric User values or unusual /etc/passwd entries mapping large numbers to privileged accounts.

Why prioritize this

This is a high-severity privilege escalation vulnerability that directly undermines Kubernetes security boundaries. A CVSS score of 7.8 reflects the high impact (privilege escalation to root) and relatively low friction for exploitation in supply-chain-compromised scenarios. Although it requires image push access or malicious image consumption, the result is complete container privilege escalation. Organizations with strict runAsNonRoot policies should treat this as critical. Environments without image signature enforcement or admission controls are at elevated risk and should prioritize patching within 30 days.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) is driven by: (1) High confidentiality, integrity, and availability impact—root access allows data theft, modification, and disruption; (2) Local attack vector—the attacker must provide or influence the image; (3) No privileges required—the vulnerability is triggered by normal container launch; (4) User interaction required—a user or controller must pull and launch the image, slightly reducing the attack vector. The score appropriately reflects the severity of privilege escalation but does not fully capture supply-chain risk; in a truly compromised registry scenario, the risk could be substantially higher.

Frequently asked questions