Containerd — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/containerd/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 21 May 2026 21:41:41 +0000Containerd runAsNonRoot Bypass via Crafted User Directive (CVE-2026-46680)https://feed.craftedsignal.io/briefs/2026-05-containerd-runasnonroot-bypass/Thu, 21 May 2026 21:41:41 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-containerd-runasnonroot-bypass/A vulnerability in containerd allows for bypassing the Kubernetes `runAsNonRoot` restriction by exploiting a misinterpretation of large numeric User directives in container images, potentially leading to container execution as root (UID 0); this is tracked as CVE-2026-46680 and CVE-2024-40635.A vulnerability exists within containerd that allows a malicious container image to bypass the runAsNonRoot security context in Kubernetes. This occurs when a container image specifies a numeric User directive that is too large to be parsed as a standard 32-bit integer, which containerd then incorrectly interprets as a username. If the attacker crafts a malicious image with an /etc/passwd file that maps this large numeric string to root, the container will execute as root, subverting intended security policies. This issue affects containerd versions before 2.3.1, 2.2.4, 2.0.9, and 1.7.32. Exploitation could lead to unauthorized access and privilege escalation within the containerized environment. This bypass impacts security implementations relying on runAsNonRoot to enforce least privilege. The vulnerability is identified as CVE-2026-46680 and CVE-2024-40635.

Attack Chain

  1. Attacker creates a malicious container image with a crafted /etc/passwd file.
  2. The /etc/passwd file maps a large numeric string (e.g., “9999999999”) to UID 0 (root).
  3. The Dockerfile for the image includes a USER directive using this large numeric string (e.g., USER 9999999999).
  4. The attacker deploys a pod to Kubernetes that uses the malicious image, but includes the runAsNonRoot: true securityContext option to enforce non-root execution.
  5. Containerd attempts to start the container. Due to the vulnerability, containerd misinterprets the large numeric string as a username.
  6. Containerd consults the /etc/passwd file within the image and incorrectly resolves the large numeric username to UID 0 (root).
  7. The container is launched and executes as root, bypassing the intended runAsNonRoot restriction.
  8. Attacker gains unauthorized root access within the container, potentially escalating privileges further within the cluster.

Impact

Successful exploitation of this vulnerability allows attackers to bypass the runAsNonRoot security context in Kubernetes, forcing containers to run as root even when explicitly restricted. This can lead to privilege escalation, unauthorized access to sensitive data, and potential compromise of the entire Kubernetes cluster. The impact is especially severe in environments where runAsNonRoot is a critical security control for preventing container escape and lateral movement. The number of affected systems depends on the prevalence of vulnerable containerd versions and the reliance on runAsNonRoot for security enforcement.

Recommendation

  • Upgrade containerd to versions 2.3.1, 2.2.4, 2.0.9, or 1.7.32 to patch the vulnerability as described in the advisory [GHSA-fqw6-gf59-qr4w].
  • Enforce a specific numeric runAsUser in the Kubernetes Pod securityContext to override the USER directive in the image as a workaround.
  • Deploy the Sigma rule “Detect Containerd runAsNonRoot Bypass via Large UID” to identify exploitation attempts by detecting pods using images with a large UID as the user.
  • Monitor container images for suspicious /etc/passwd files that map large numeric strings to UID 0.
]]>highadvisoryrunAsNonRootprivilege-escalationcontainerdkubernetes