Search for packages
| purl | pkg:deb/debian/containerd@2.1.6%2Bds1-1?distro=trixie |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-1ucu-ewxj-xfhp | Multiple vulnerabilities have been found in containerd, the worst of which could result in privilege escalation. |
CVE-2022-31030
GHSA-5ffw-gxpp-mxpf |
| VCID-3brf-dmwm-qkgj | Supplementary groups are not set up properly in github.com/containerd/containerd ### 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](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2023-25173
GHSA-hmfx-3pcx-653p |
| VCID-3pwn-3668-4yev | containerd allows host filesystem access on pull ### Impact A time-of-check to time-of-use (TOCTOU) vulnerability was found in containerd v2.1.0. While unpacking an image during an image pull, specially crafted container images could arbitrarily modify the host file system. ### Patches This bug has been fixed in the following containerd versions: * 2.1.1 The only affected version of containerd is 2.1.0. Other versions of containerd are not affected. Users should update to this version 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 Tõnis Tiigi for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-47290 ### For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2025-47290
GHSA-cm76-qm8v-3j95 |
| VCID-4qfu-ng4n-jbfx | Multiple vulnerabilities have been found in containerd, the worst of which could result in privilege escalation. |
CVE-2021-32760
GHSA-c72p-9xmj-rx3w |
| VCID-6vru-hsfs-rufg | Multiple vulnerabilities have been found in containerd, the worst of which could result in privilege escalation. |
CVE-2020-15257
GHSA-36xw-fx78-c5r4 |
| VCID-9qpc-77v8-13hw | Moby (Docker Engine) started with non-empty inheritable Linux process capabilities ### Impact A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. ### Patches This bug has been fixed in Moby (Docker Engine) 20.10.14. Users should update to this version as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. Refer to `capabilities(7)` for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox. ### Workarounds The entrypoint of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting. ### Credits The Moby project would like to thank [Andrew G. Morgan](https://github.com/AndrewGMorgan) for responsibly disclosing this issue in accordance with the [Moby security policy](https://github.com/moby/moby/blob/master/SECURITY.md). ### For more information If you have any questions or comments about this advisory: * [Open an issue](https://github.com/moby/moby/issues/new) * Email us at [security@docker.com](mailto:security@docker.com) if you think you’ve found a security bug |
CVE-2022-24769
GHSA-2mm7-x5h6-5pvq |
| VCID-az9e-udkj-8kck | containerd CRI plugin: Incorrect cgroup hierarchy assignment for containers running in usernamespaced Kubernetes pods. # Impact A bug was found in the containerd's CRI implementation where containerd doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. # Patches This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. # Workarounds Disable usernamespaced pods in Kubernetes temporarily. # Credits The containerd project would like to thank Rodrigo Campos Catelin and Piotr Rogowski for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). # For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at security@containerd.io To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2025-47291
GHSA-cxfp-7pvr-95ff |
| VCID-d42a-4prp-m7hb | Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux ### Impact Containers launched through containerd’s CRI implementation on Linux systems which use the SELinux security module and containerd versions since v1.5.0 can cause arbitrary files and directories on the host to be relabeled to match the container process label through the use of specially-configured bind mounts in a hostPath volume. This relabeling elevates permissions for the container, granting full read/write access over the affected files and directories. Kubernetes and crictl can both be configured to use containerd’s CRI implementation. If you are not using containerd’s CRI implementation (through one of the mechanisms described above), you are not affected by this issue. ### Patches This bug has been fixed in containerd 1.5.9. Because file labels persist independently of containerd, users should both update to these versions as soon as they are released and validate that all files on their host are correctly labeled. ### Workarounds Ensure that no sensitive files or directories are used as a hostPath volume source location. Policy enforcement mechanisms such a Kubernetes Pod Security Policy [AllowedHostPaths](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) may be specified to limit the files and directories that can be bind-mounted to containers. ### For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2021-43816
GHSA-mvff-h3cj-wj9c |
| VCID-f2yv-ut5v-m7ey | containerd affected by a local privilege escalation via wide permissions on CRI directory ### 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](https://github.com/containerd/containerd/blob/main/docs/rootless.md). ### Credits The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) |
CVE-2024-25621
GHSA-pwhc-rpq9-4c8w |
| VCID-gbw6-3a59-mbhu | containerd v1.2.x can be coerced into leaking credentials during image pull ## Impact If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N. ## Patches This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. ## Workarounds If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. ## Credits The containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/master/SECURITY.md). |
CVE-2020-15157
GHSA-742w-89gc-8m9c |
| VCID-kuwr-ugf2-rke4 | Insufficiently restricted permissions on plugin directories ### 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](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2021-41103
GHSA-c2h3-6mxw-7mvq |
| VCID-t345-zgxj-6keq | containerd environment variable leak ## Impact Containers launched through containerd's CRI implementation (through Kubernetes, crictl, or any other pod/container client that uses the containerd CRI service) that share the same image may receive incorrect environment variables, including values that are defined for other containers. If the affected containers have different security contexts, this may allow sensitive information to be unintentionally shared. If you are not using containerd’s CRI implementation (through one of the mechanisms described above), you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image which have different environment variables, you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image in rapid succession, you have reduced likelihood of being vulnerable to this issue ## Patches This vulnerability has been fixed in containerd 1.3.10 and containerd 1.4.4. Users should update to these versions as soon as they are released. ## Workarounds There are no known workarounds. ## For more information If you have any questions or comments about this advisory: * [Open an issue](https://github.com/containerd/containerd/issues/new/choose) * Email us at security@containerd.io if you think you’ve found a security bug. |
CVE-2021-21334
GHSA-6g2q-w5j3-fwh4 |
| VCID-tc5s-4nx2-y7d9 | Multiple vulnerabilities have been found in containerd, the worst of which could result in privilege escalation. |
CVE-2022-23471
GHSA-2qjp-425j-52j9 |
| VCID-twq1-g136-9kc3 | containerd has an integer overflow in User ID handling ### 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](https://github.com/p4ck3t0) and [emxll](https://github.com/emxll) for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### 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](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2024-40635
GHSA-265r-hfxg-fhmg |
| VCID-xd4a-qav4-uqd1 | containerd CRI server: Host memory exhaustion through Attach goroutine leak ### 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`](https://kubernetes.io/docs/reference/kubectl/generated/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](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). ### Credits The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### 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](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) |
CVE-2025-64329
GHSA-m6hq-p25p-ffr2 |
| VCID-yyye-gaug-8uh2 | OCI image importer memory exhaustion in github.com/containerd/containerd ### 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](https://github.com/DavidKorczynski) and [Adam Korczynski](https://github.com/AdamKorcz) of ADA Logics for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md) 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](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) |
CVE-2023-25153
GHSA-259w-8hf6-59c2 |
| VCID-zedh-ff93-yka4 | Multiple vulnerabilities have been found in containerd, the worst of which could result in privilege escalation. |
CVE-2022-23648
GHSA-crp2-qrr5-8pq7 |