Impact containerd's CRI checkpoint import process contains a vulnerability where it fails to validate the image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node's local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an IfNotPresent (or Never) pull policy, they will unknowingly execute the attacker's malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod's identity.
Patches This bug has been fixed in the following containerd versions:
2.3.2 2.2.5 2.1.9
Users should update to these versions to resolve the issue. Workarounds Users should only allow trusted images to be pulled.
Credits The containerd project would like to thank Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, and Robert Prast (@robertprast) who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact A bug was found in containerd where the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations.
Patches This bug has been fixed in the following containerd versions:
2.3.2 2.2.5 2.1.9 2.0.10 1.7.33
Users should update to these versions to resolve the issue.
Workarounds Ensure that only trusted images are used.
Credits The containerd project would like to thank Anthropic Research, in collaboration with Claude, the GKE Security Team using Gemini, and Robert Prast (@robertprast) for independently discovering and responsibly disclosing this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact A bug was found in containerd where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs.
Patches This bug has been fixed in the following containerd versions:
2.3.2 2.2.5 2.1.9
Users should update to these versions to resolve the issue.
Workarounds Ensure that only trusted images and checkpoints are used.
Credits The containerd project would like to thank @gouldnicholas and @davidrxchester, Yuming Zhang and Song Li of Zhejiang University, Sangwon Ryu (@sangwon090), Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, Robert Prast (@robertprast), Kyle Elliott (@kyle-elliott-tob) of Trail of Bits, and Zhenchen Wang (@Plucky923), who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact
containerd's CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected.
Patches
This bug has been fixed in the following containerd versions:
2.3.2 2.2.5 2.1.9
Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration.
Workarounds
Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (/etc/cdi and /var/run/cdi) will eliminate the reachability of this vulnerability.
Credits
The containerd project would like to thank Robert Prast (@robertprast) for responsibly disclosing this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact A vulnerability in containerd allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components.
Patches This bug has been fixed in the following containerd versions:
2.3.2 2.2.5 2.1.9 2.0.10 1.7.33
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 or schedule pods.
Credits
The containerd project would like to thank Jakub Ciolek (@jake-ciolek) at AlphaSense and Kyle Elliott @ Trail of Bits who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
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 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.
Resources https://github.com/advisories/GHSA-265r-hfxg-fhmg (CVE-2024-40635)
For more information
If there are any questions or comments about this advisory:
Open an issue in containerd Send an email to security@containerd.io
To report a security issue in containerd: Report a new vulnerability Send an email to security@containerd.io
Impact
A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks.
Repetitive calls of CRI Attach (e.g., kubectl attach) could increase the memory usage of containerd.
Patches
This bug has been fixed in the following containerd versions:
2.2.0 2.1.5 2.0.7 1.7.29
Users should update to these versions to resolve the issue.
Workarounds
Set up an admission controller to control accesses to pods/attach resources. e.g., Validating Admission Policy.
Credits
The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the containerd security policy.
References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd:
Report a new vulnerability
Impact
An overly broad default permission vulnerability was found in containerd.
- /var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700 - Allowed local users on the host to potentially access the metadata store and the content store - /run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700 - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host. - /run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700
The directory paths may differ depending on the daemon configuration. When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.
Patches
This bug has been fixed in the following containerd versions:
2.2.0 2.1.5 2.0.7 1.7.29
Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories.
[!NOTE] /run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711. This is an expected behavior for supporting userns-remapped containers.
Workarounds
The system administrator on the host can manually chmod the directories to not have group or world accessible permisisons:
chmod 700 /var/lib/containerd chmod 700 /run/containerd/io.containerd.grpc.v1.cri chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
An alternative mitigation would be to run containerd in rootless mode.
Credits
The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd:
Report a new vulnerability
Impact A bug was found in containerd where containers launched with a User set as a UID:GID larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause 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.0.4 (Fixed in https://github.com/containerd/containerd/commit/1a43cb6a1035441f9aca8f5666a9b3ef9e70ab20) 1.7.27 (Fixed in https://github.com/containerd/containerd/commit/05044ec0a9a75232cad458027ca83437aae3f4da) 1.6.38 (Fixed in https://github.com/containerd/containerd/commit/cf158e884cfe4812a6c371b59e4ea9bc4c46e51a)
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.
Credits The containerd project would like to thank Benjamin Koltermann and emxll for responsibly disclosing this issue in accordance with the containerd security policy.
References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-40635
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact
A bug was found in containerd where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.
Downstream applications that use the containerd client library may be affected as well.
Patches This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions.
Workarounds
Ensure that the "USER $USERNAME" Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to ENTRYPOINT ["su", "-", "user"] to allow su to properly set up supplementary groups.
References
- https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/ - Docker/Moby: CVE-2022-36109, fixed in Docker 20.10.18 - CRI-O: CVE-2022-2995, fixed in CRI-O 1.25.0 - Podman: CVE-2022-2989, fixed in Podman 3.0.1 and 4.2.0 - Buildah: CVE-2022-2990, fixed in Buildah 1.27.1
Note that CVE IDs apply to a particular implementation, even if an issue is common.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact When importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service.
Patches
This bug has been fixed in containerd 1.6.18 and 1.5.18. 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.
Credits
The containerd project would like to thank David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the containerd security policy during a security fuzzing audit sponsored by CNCF.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io
Impact A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files.
Patches This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability.
Workarounds Limit access to the host to trusted users. Update directory permission on container bundles directories.
For more information If you have any questions or comments about this advisory: Open an issue in github.com/containerd/containerd Email us at security@containerd.io
A flaw was found in containerd. Credentials may be leaked during an image pull.