CVE-2026-46680

What it actually does

The flaw is an authorization bypass in containerd’s handling of container image user identity. When an image specifies a numeric User value that is too large to fit in a 32-bit integer, containerd incorrectly falls back to treating that value as a username rather than rejecting it or preserving it as an invalid numeric UID. A malicious image can include an /etc/passwd entry where that oversized numeric string resolves to UID 0, causing the container process to run as root. In Kubernetes, this can bypass runAsNonRoot controls because the image appears to specify a non-root-looking user while runtime resolution ultimately starts the container as UID 0.

Why it matters to the business

Organizations relying on Kubernetes or container policies to enforce non-root execution may unknowingly run workloads with root privileges inside containers. This weakens isolation, increases the blast radius of application compromise, and can undermine compliance requirements that mandate non-root containers. Although EPSS is currently low and the issue is not listed in CISA KEV, the impact is significant for environments that admit third-party, developer-supplied, or externally built container images.

How an attack unfolds

An attacker builds or supplies a container image whose OCI image configuration sets the User field to a very large numeric string that cannot be parsed as a 32-bit integer. The same image contains an /etc/passwd file with an entry whose username exactly matches that large numeric string and whose UID is 0. When the image is launched by an affected containerd runtime, the invalid numeric User value is misinterpreted as a username. containerd resolves that username through the image’s passwd database and starts the process as root. In Kubernetes environments, the pod may satisfy or bypass expected non-root policy checks while the actual container process runs with UID 0, giving the attacker root privileges inside the container and increasing the ability to modify files, abuse Linux capabilities, or attempt further container escape chains if other weaknesses are present.

How to fix it

Upgrade containerd to a version that correctly validates oversized numeric User values and prevents this parsing confusion. If exact fixed versions are not yet mapped in the available inventory, consult the containerd security advisory and your Linux distribution, Kubernetes platform, or managed Kubernetes provider advisories for the patched package versions. As compensating controls, enforce image admission policies that reject images with numeric User values outside the valid UID range, reject images whose configured user resolves to UID 0, and require explicit non-root numeric UIDs within an approved range. Strengthen Kubernetes Pod Security Admission, OPA Gatekeeper, Kyverno, or equivalent controls to validate image metadata where possible, and avoid allowing untrusted images to run without scanning and admission review.

How to confirm the fix worked

Confirm all nodes and container runtime packages are running patched containerd builds from the appropriate vendor channel. Validate exposure by inspecting containerd versions across Kubernetes nodes and hosts, then review admitted images for OCI config User values that are numeric and greater than 2147483647 or otherwise outside expected UID ranges. For a functional validation, test in a non-production environment with policy-safe checks to ensure images with oversized numeric users are rejected or do not start as UID 0. Confirm running workloads with runAsNonRoot expectations are actually running as non-root by checking effective UIDs inside containers or through runtime inspection tooling.

Typical attack path

1. Create or modify a container image with an oversized numeric User directive that exceeds 32-bit integer parsing limits.
2. Add an /etc/passwd entry inside the image where that oversized numeric string maps to UID 0.
3. Publish or introduce the crafted image into a registry, CI/CD workflow, or Kubernetes deployment path.
4. Deploy the image to a node using an affected containerd version, often in a namespace or cluster that expects runAsNonRoot enforcement.
5. containerd treats the oversized numeric value as a username and resolves it to the root UID through the image passwd file.
6. The container starts as UID 0 despite non-root expectations, allowing the attacker-controlled workload to run with root privileges inside the container.

How to detect it

To determine whether this was already exploited, examine container image metadata, Kubernetes audit logs, registry events, and runtime state. Look for pod or workload creations using images whose OCI config User field is a large numeric string outside the normal UID range, especially greater than 2147483647, combined with image /etc/passwd entries mapping that same string to UID 0. Review admission-controller logs, image scanner output, CI/CD build artifacts, and registry manifests for suspicious User values. On running or historical workloads, compare declared Kubernetes securityContext settings such as runAsNonRoot: true with the actual UID observed at runtime; a container expected to be non-root but running as UID 0 is suspicious. Investigate any associated image publisher, build job, deployment actor, or service account that introduced the image. Also review runtime telemetry for root-only activity inside supposedly non-root containers, such as package installation, writes to privileged filesystem paths, capability changes, or attempts to access host mounts.

• "User":"2147483648"
• "User":"4294967296"
• "User":"9999999999"
• "User": "2147483648"
• "User": "4294967296"
• "User": "9999999999"
• 2147483648:x:0:0:
• 4294967296:x:0:0:
• 9999999999:x:0:0:
• USER 2147483648
• USER 4294967296
• USER 9999999999
• runAsNonRoot: true
• /etc/passwd

What your security team should do

• Prioritize patching containerd on Kubernetes worker nodes and any standalone container hosts that run untrusted or semi-trusted images.
• Inventory running and recently deployed images for oversized numeric User directives and passwd entries mapping unusual usernames to UID 0.
• Add admission controls to block images with empty, root, oversized, or non-approved User values before deployment.
• Require CI/CD image builds to set an explicit non-root numeric UID and fail builds that include suspicious /etc/passwd mappings to UID 0.
• Review Kubernetes workloads that rely on runAsNonRoot and verify their actual runtime UID is non-root.
• Monitor registry, deployment, and audit logs for newly introduced images with anomalous User metadata.
• Treat any discovered workload exploiting this behavior as potentially compromised and investigate image provenance, build pipeline access, and runtime activity.