## 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](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 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](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 import allows local image tag poisoning 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 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](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 import allows local image tag poisoning 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 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](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