Affected: Go: github.com/containerd/containerd, Go: github.com/containerd/containerd/v2

### Impact A bug was found in containerd where containers launched with a numeric `User` directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. If a crafted image provides an `/etc/passwd` file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes `runAsNonRoot` restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user.

### Patches This bug has been fixed in the following containerd versions:

* 2.3.1 * 2.2.4 * 2.0.9 * 1.7.32

Note: The containerd 2.1 release has reached its [end of life](https://containerd.io/releases/#current-state-of-containerd-releases) and a fixed version is not provided.

Users should update to these versions to resolve the issue.

### Workarounds Ensure that only trusted images are used and that only trusted users have permissions to import images. Alternatively, enforcing a specific numeric `runAsUser` in the Kubernetes Pod `securityContext` overrides the `USER` directive in the image and prevents the bypass. Newer versions of Kubernetes, starting with 1.34, also appear to enforce `runAsNonRoot` properly regardless of this bug.

### Credits The containerd project would like to thank Lei Wang (@ssst0n3) for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### Resources * https://github.com/a…