Package Instance

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)

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)

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)