https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 04:31:00 +0000 https://db.gcve.eu/vuln/ghsa-fqw6-gf59-qr4w <p><strong>Affected:</strong> Go: github.com/containerd/containerd, Go: github.com/containerd/containerd/v2</p> <p>### 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.</p> <p>### Patches This bug has been fixed in the following containerd versions:</p> <p>* 2.3.1 * 2.2.4 * 2.0.9 * 1.7.32</p> <p>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.</p> <p>Users should update to these versions to resolve the issue.</p> <p>### 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.</p> <p>### 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).</p> <p>### Resources * https://github.com/a…</p> <p><strong>Affected:</strong> Go: github.com/containerd/containerd, Go: github.com/containerd/containerd/v2</p> <p>### 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.</p> <p>### Patches This bug has been fixed in the following containerd versions:</p> <p>* 2.3.1 * 2.2.4 * 2.0.9 * 1.7.32</p> <p>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.</p> <p>Users should update to these versions to resolve the issue.</p> <p>### 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.</p> <p>### 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).</p> <p>### Resources * https://github.com/a…</p> https://db.gcve.eu/vuln/ghsa-fqw6-gf59-qr4w