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.
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 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 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.
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's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO.
Patches
This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.
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
An incorrect permission assignment flaw was found in containerd. This flaw allows a local attacker to use a specially designed text file to read and write files outside of the container's scope.
Impact
A bug was found in containerd where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host’s filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process.
Patches
This bug has been fixed in containerd 1.5.4 and 1.4.8. Users should update to these versions as soon as they are released. Running containers do not need to be restarted.
Workarounds
Ensure you only pull images from trusted sources.
Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with unexpected files.
For more information
If you have any questions or comments about this advisory:
Open an issue Email us at security@containerd.io if you think you’ve found a security bug.
Impact
Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges.
Specific Go Packages Affected github.com/containerd/containerd/cmd
Patches
This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade.
Workarounds
If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue.
If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@, to your policy.
It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container.
Credits
The containerd maintainers would like to thank Jeff Dileo of NCC Group for responsibly disclosing this issue in accordance with the containerd security policy and for reviewing the patch.
For more information
If you have any questions or comments about this advisory:
Open an issue Email us at security@containerd.io if you think you’ve found a security bug.
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 Email us at security@containerd.io if you think you’ve found a security bug.
Impact
A bug was found in containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility.
Patches
This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images and commands are used.
References
Similar fix in cri-o's CRI implementation https://github.com/cri-o/cri-o/security/advisories/GHSA-fcm2-6c3h-pg6j
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 audit sponsored by CNCF and facilitated by OSTIF.
For more information
If you have any questions or comments about this advisory:
Open an issue in containerd Email us at security@containerd.io
Impact
A bug was found in containerd where containers launched through containerd’s CRI implementation with a specially-crafted image configuration could gain access to read-only copies of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information. Kubernetes and crictl can both be configured to use containerd’s CRI implementation.
Patches
This bug has been fixed in containerd 1.6.1, 1.5.10 and 1.4.13. 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 Felix Wilhelm of Google Project Zero 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
End of life: 2/28/2023, End of support: 8/15/2022, Latest version: 1.5.18
End of life: 2/28/2023, End of support: 8/15/2022, Latest version: 1.5.18
End of life: 3/3/2022, End of support: 11/3/2021, Latest version: 1.4.13
End of life: 3/3/2022, End of support: 11/3/2021, Latest version: 1.4.13
End of life: 3/4/2021, End of support: 3/4/2021, Latest version: 1.3.10
End of life: 3/4/2021, End of support: 3/4/2021, Latest version: 1.3.10
End of life: 10/15/2020, End of support: 3/26/2020, Latest version: 1.2.14
End of life: 10/15/2020, End of support: 3/26/2020, Latest version: 1.2.14
End of life: 10/23/2019, End of support: 10/23/2019, Latest version: 1.1.8
End of life: 10/23/2019, End of support: 10/23/2019, Latest version: 1.1.8
End of life: 12/5/2018, End of support: 12/5/2018, Latest version: 1.0.3
End of life: 12/5/2018, End of support: 12/5/2018, Latest version: 1.0.3