CVE-2026-46680 Overview
CVE-2026-46680 is a privilege escalation vulnerability in containerd, an open-source container runtime widely used by Kubernetes and Docker. The flaw allows a crafted container image to bypass the Kubernetes runAsNonRoot restriction. When a numeric User directive exceeds the range of a 32-bit integer, containerd incorrectly treats the value as a username rather than a UID. A malicious /etc/passwd file inside the image can then map that string to UID 0, causing the container to run as root. The issue is fixed in containerd versions 1.7.32, 2.0.9, 2.2.4, and 2.3.1.
Critical Impact
A crafted container image can escape the runAsNonRoot policy and execute as root (UID 0), undermining a foundational Kubernetes hardening control.
Affected Products
- containerd versions prior to 1.7.32
- containerd 2.0.x versions prior to 2.0.9
- containerd 2.2.x versions prior to 2.2.4 and 2.3.x versions prior to 2.3.1
Discovery Timeline
- 2026-07-01 - CVE-2026-46680 published to NVD
- 2026-07-02 - Last updated in NVD database
Technical Details for CVE-2026-46680
Vulnerability Analysis
The vulnerability stems from how containerd parses the User directive supplied in an image configuration or pod spec. Container runtimes typically accept either a numeric UID or a username that must be resolved against the image's /etc/passwd. containerd attempts to parse the User value as a 32-bit integer to treat it as a UID.
When the value exceeds the 32-bit integer range, parsing fails silently and containerd falls back to username resolution. An attacker who controls the image can publish an /etc/passwd entry that maps that oversized numeric string to UID 0. The Kubernetes admission check for runAsNonRoot inspects the declared numeric value, sees a non-zero integer-like string, and permits the pod. The container then launches as root, defeating the policy.
The weakness is classified under [CWE-269] Improper Privilege Management.
Root Cause
The root cause is inconsistent handling of the User field between the admission-time check and the runtime resolution path. runAsNonRoot validation and containerd's UID parser disagree on how to interpret numeric strings that overflow a 32-bit signed integer. This TOCTOU-like gap lets a crafted image redirect the numeric identifier to a username lookup that resolves to root.
Attack Vector
Exploitation requires an attacker to supply or influence the container image executed on a target cluster. The attacker builds an image whose USER directive is a large numeric string outside 32-bit integer range and whose /etc/passwd maps that string to UID 0. When the pod is scheduled under a runAsNonRoot: true security context, admission control accepts it and containerd launches the workload with root privileges inside the container namespace. From there, an attacker gains a stronger foothold to attempt container escapes, mount abuses, or capability-based attacks.
No public proof-of-concept exploit code has been released. The GitHub Security Advisory GHSA-fqw6-gf59-qr4w describes the mechanism in detail. See the containerd Security Advisory for authoritative technical background.
Detection Methods for CVE-2026-46680
Indicators of Compromise
- Container images whose USER directive contains numeric strings larger than 2147483647 or otherwise outside 32-bit signed integer range.
- Image layers containing an /etc/passwd entry that maps a very large numeric login name to UID 0.
- Running containers reporting effective UID 0 despite being scheduled under a pod spec with runAsNonRoot: true.
Detection Strategies
- Scan image manifests and Dockerfiles in registries for USER values that cannot be parsed as a 32-bit integer.
- Inspect /etc/passwd inside images for entries mapping numeric-looking usernames to UID 0.
- Compare the runtime UID reported by containerd (ctr or CRI status) against the pod spec's declared runAsUser and runAsNonRoot values.
Monitoring Recommendations
- Audit Kubernetes admission logs and containerd CreateContainer events for anomalous User fields.
- Enable Pod Security Admission at the restricted level and forward audit logs to a centralized data lake for correlation.
- Alert on any process with UID 0 inside pods that declare runAsNonRoot: true.
How to Mitigate CVE-2026-46680
Immediate Actions Required
- Upgrade containerd to 1.7.32, 2.0.9, 2.2.4, or 2.3.1 on every node in the cluster.
- Restart the containerd service on each node after the binary is replaced so the fix takes effect.
- Restrict image pulls to trusted registries and enforce image signature verification through tools such as Sigstore or Notary.
Patch Information
The containerd maintainers released fixes in versions 1.7.32, 2.0.9, 2.2.4, and 2.3.1. The corrected parser rejects User values that cannot be represented as a valid 32-bit UID rather than falling back to username lookup. Full remediation details are provided in GHSA-fqw6-gf59-qr4w.
Workarounds
- Explicitly set runAsUser to a known non-zero numeric UID in every pod spec instead of relying solely on runAsNonRoot.
- Use a Pod Security Admission policy or an OPA/Kyverno rule that rejects User values outside the range 1 to 2147483647.
- Block images whose /etc/passwd maps numeric-looking usernames to UID 0 during CI/CD image scanning.
# Kyverno policy fragment: reject pods whose runAsUser is missing or out of range
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-numeric-non-root-uid
spec:
validationFailureAction: Enforce
rules:
- name: require-valid-runasuser
match:
any:
- resources:
kinds: [Pod]
validate:
message: "runAsUser must be an integer between 1 and 2147483647"
pattern:
spec:
securityContext:
runAsNonRoot: true
runAsUser: ">0 & <2147483648"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

