### 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](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 [[email protected]](mailto:[email protected]) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [[email protected]](mailto:[email protected])
### 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](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 [[email protected]](mailto:[email protected]) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [[email protected]](mailto:[email protected])
Update github.com/containerd/containerd/v2 to 2.1.9; github.com/containerd/containerd/v2 to 2.2.5; github.com/containerd/containerd/v2 to 2.3.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scancontainerd CRI checkpoint restore CDI annotation smuggling affects github.com/containerd/containerd/v2 (go), github.com/containerd/containerd/v2 (go), github.com/containerd/containerd/v2 (go). Severity is critical. ### 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](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 [[email protected]](mailto:[email protected]) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [[email protected]](mailto:[email protected])
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/containerd/containerd/v2go | >=2.1.0,<2.1.9 | 2.1.9 |
| github.com/containerd/containerd/v2go | >=2.2.0,<2.2.5 | 2.2.5 |
| github.com/containerd/containerd/v2go | >=2.3.0,<2.3.2 | 2.3.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/containerd/containerd/v2 to 2.1.9; github.com/containerd/containerd/v2 to 2.2.5; github.com/containerd/containerd/v2 to 2.3.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scancontainerd CRI checkpoint restore CDI annotation smuggling affects github.com/containerd/containerd/v2 (go), github.com/containerd/containerd/v2 (go), github.com/containerd/containerd/v2 (go). Severity is critical. ### 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](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 [[email protected]](mailto:[email protected]) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [[email protected]](mailto:[email protected])
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/containerd/containerd/v2go | >=2.1.0,<2.1.9 | 2.1.9 |
| github.com/containerd/containerd/v2go | >=2.2.0,<2.2.5 | 2.2.5 |
| github.com/containerd/containerd/v2go | >=2.3.0,<2.3.2 | 2.3.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard