リリース

containerd v2.1.9 is a security-focused patch release fixing 5 CVEs. Upgrade immediately if you run any containerd 2.1.x deployment.

• securityPatch 5 CVEs — upgrade containerd 2.1.x now

  This release closes 5 CVEs in containerd itself. The advisories are not yet public so severity details are unavailable, but 5 CVEs in a single patch release is unusually high. Any team running containerd 2.1.x on production nodes should plan an upgrade this week. Check your Kubernetes node images, managed node groups, and any bare-metal CRI setups.

• securityrunc updated to v1.3.6 — verify your runc version separately

  The bundled runc binary ships as v1.3.6, which likely carries its own fixes. If you manage runc independently (common on Kubernetes nodes), confirm you are also running v1.3.6 or later — upgrading containerd alone will not replace a separately installed runc binary.

• enhancementCheckpoint restore hardened against malicious archive content

  Three CRI fixes tighten checkpoint/restore: unexpected archive content is now rejected, re-tagging of restored checkpoints is skipped, and CDI annotations are filtered. If your team uses container checkpointing (e.g., CRIU-based live migration), test restore workflows after upgrading to confirm behavior is unchanged.

containerd 1.7.33 patches two containerd CVEs and one go-jose CVE, updates runc to v1.3.6, and bumps Go. Security-only motivation to upgrade.

• securityUpgrade to 1.7.33 for three CVE fixes

  Two CVEs in containerd itself (CVE-2026-53488, CVE-2026-47262) and one in go-jose (CVE-2026-34986) are patched here. Full details are in the GitHub security advisories. If you are running containerd 1.7.x in production, upgrade now — there is no other reason to stay on an earlier 1.7.x patch.

• securityReserved labels can no longer leak from image configs

  A fix was added to prevent reserved labels being propagated from image configs. If your environment relies on label-based access control or policy enforcement, verify that behavior is unchanged after upgrading and check the advisory for CVE-2026-47262 for scope.

• enhancementrunc updated to v1.3.6

  The bundled runc binary moves from whatever 1.7.32 shipped to v1.3.6. If you manage runc separately, make sure your installed version is at least v1.3.6 to stay consistent with what containerd expects.

containerd v2.0.10 patches two CVEs (CVE-2026-53488, CVE-2026-47262) and updates runc to v1.3.6. Upgrade promptly if running 2.0.x in production.

• securityTwo CVEs fixed — upgrade now

  CVE-2026-53488 and CVE-2026-47262 are both addressed in this release. The advisories (GHSA-xhf5-7wjv-pqxp and GHSA-jpcc-p29g-p8mq) have full details on impact and scope. Any containerd 2.0.x node running in production should be upgraded to v2.0.10 before assessing whether you're actually exposed — these are runtime-level issues and the blast radius can be broad.

• securityrunc bumped to v1.3.6

  The runc binary shipped with containerd is updated to v1.3.6, which itself carries fixes from v1.3.4 and v1.3.5. If you manage runc separately (e.g., installed via package manager), verify your runc version independently and align it with v1.3.6.

• enhancementImage config reserved labels no longer propagate

  Labels reserved by containerd are now stripped from image configs before use. If you rely on any tooling that reads propagated reserved labels from running containers, test behavior after upgrading — this is a quiet behavioral change that may affect label-based automation.

containerd 2.3.2 is a security-heavy patch release fixing 5 CVEs alongside runtime stability fixes. Upgrade promptly if you're running 2.3.x in production.

• security5 CVEs fixed — upgrade 2.3.x nodes now

  Five CVEs are patched in this release, covering containerd's core. The advisories are not yet fully public, but the breadth (5 in one patch) suggests meaningful attack surface. Teams running containerd 2.3.x in any environment should upgrade to 2.3.2 without waiting for the next maintenance window. Check your node provisioning pipelines and update the containerd binary alongside runc (now v1.4.3).

• enhancementRetry on transient network errors during image pull

  The resolver now retries on transient network errors when the last configured host is tried. This reduces pull failures in flaky network environments without requiring any config change. No action needed, but useful context if you've been seeing intermittent image pull errors under network instability.

• enhancementSlow container creation no longer causes RPC timeout failures

  A lock in the runc shim was held across the runc create call, causing concurrent RPC timeouts and startup failures when container creation was slow. This is now fixed. If you've seen containers stuck or failing to start under load, this patch likely addresses it.

containerd 2.2.5 is a security-heavy patch release fixing 5 CVEs, with runc bumped to v1.3.6 and Go updated to 1.26.4/1.25.11. Upgrade promptly if running 2.2.x.

• securityPatch 5 CVEs — upgrade 2.2.x nodes now

  This release closes 5 CVEs in containerd itself. Details are in the linked security advisories. Any cluster running containerd 2.2.x should upgrade to 2.2.5. The runc bump to v1.3.6 may also carry its own fixes — check the runc release notes before rolling out.

• securitygolang.org/x/crypto and net updated — relevant if you build custom plugins

  golang.org/x/crypto jumped from v0.45.0 to v0.53.0 and golang.org/x/net from v0.47.0 to v0.55.0. If you vendor containerd or build plugins against its libraries, re-vendor and rebuild. The crypto jump in particular covers several upstream security fixes across that range.

• enhancementCheckpoint/restore is more reliable in this release

  Three separate CRI fixes land here: CDI annotations are now filtered on checkpoint restore, restored checkpoints are no longer incorrectly re-tagged, and the restore path is hardened against malformed archive content. If you use container checkpoint/restore in production, this release is worth prioritizing.

Security patch release fixing CVE-2026-46680 plus runtime bugs in sandbox service, AppArmor compatibility, and OCI USER spec handling.

• securityPatch CVE-2026-46680 immediately

  CVE-2026-46680 is the primary driver for this release. Review the GHSA advisory to understand the attack surface and severity. If you run containerd 2.1.x in any environment, upgrading to 2.1.8 should be your next deployment task. There are no dependency changes, so the upgrade path is straightforward.

• breakingOCI USER out-of-range values now fail explicitly — check your container specs

  Previously, out-of-range USER values in OCI specs could silently fall through to username/group lookups, masking misconfigurations. Now containerd returns an explicit error. If any of your containers or image builds set numeric USER values outside valid UID/GID ranges, they will start failing visibly after this upgrade. Audit your specs before rolling out to production.

• enhancementUpgrade if you run AppArmor < 3.0 or use sandbox-based runtimes

  The conditional AppArmor abi fix is a real blocker for anyone on older AppArmor (e.g., Ubuntu 20.04 ships 2.x). The sandbox service bug also affects event-driven workflows and correct sandbox creation — silent misconfiguration is worse than a visible error. If you use Kata Containers or any sandbox-based runtime, this fix directly affects you.

containerd v2.2.4 is a security-focused patch release addressing two CVEs plus several runtime fixes for overlay, sandbox, AppArmor, and seccomp behavior.

• securityPatch both CVEs — update to v2.2.4 now

  Two CVEs are fixed here: one in containerd itself (CVE-2026-46680) and one in the go-jose dependency (CVE-2026-34986). Both affect production deployments. Don't wait for your next maintenance window — push this update through your standard emergency patch process. If you run containerd on Kubernetes nodes, this applies to all container runtimes backed by containerd regardless of the orchestrator.

• securityAF_ALG is now blocked by default seccomp — test custom workloads

  The default seccomp profile now blocks AF_ALG (kernel crypto API via sockets). This reduces attack surface, but any workload relying on AF_ALG sockets — unusual but possible in cryptography-heavy or hardware-offload scenarios — will start seeing syscall denials. Run a quick audit of workloads with custom or permissive seccomp profiles before upgrading in production.

• enhancementUserNS + overlay users should upgrade to fix layer extraction

  If you run rootless containers or pods using user namespaces with the overlay snapshotter, the previous 'rebase' capability caused layer extraction failures. This patch disables that capability automatically in UserNS contexts. No config change needed — just upgrade and verify your rootless workloads mount correctly post-update.

containerd 2.0.9 patches CVE-2026-46680 and fixes a TOCTOU race in tar extraction, lost container exit events on restart, and several security hardening issues.

• securityPatch CVE-2026-46680 now

  A security vulnerability tracked as CVE-2026-46680 is fixed in this release. Any containerd 2.0.x deployment should be upgraded to 2.0.9 immediately. Check the GHSA advisory for affected configurations and severity before scheduling maintenance windows — this shouldn't wait.

• securityTOCTOU fix in tar extraction reduces image unpack risk

  The TOCTOU race during tar extraction could be exploited with a crafted image layer to escape expected paths. This is relevant for any environment pulling untrusted or third-party images. Upgrade and consider auditing your image pull policies if you haven't already restricted sources.

• breakingCheck AppArmor configs if running pre-3.0 AppArmor

  The AppArmor ABI field is now set conditionally, so systems running AppArmor older than 3.0 won't have an incompatible ABI injected into generated profiles. If you've been working around this with custom profiles, test your AppArmor setup after upgrading to confirm behavior is as expected.

• enhancementFix for lost exit events matters for high-churn workloads

  If you've seen containers stuck in unexpected states after a containerd restart — particularly in Kubernetes environments with rapid pod cycling — this fix addresses the root cause. No config change needed; upgrading is enough.

containerd 1.7.32 is a security-focused patch addressing CVE-2026-46680, plus hardening the default seccomp profile by blocking AF_ALG sockets and fixing OCI spec USER handling.

• securityPatch CVE-2026-46680 now — upgrade to 1.7.32

  CVE-2026-46680 is the primary driver for this release. Details are in the containerd security advisory. If you're running any 1.7.x version, treat this as a mandatory upgrade. Check the advisory for severity and attack surface before deciding on your maintenance window — but don't defer this long.

• securityAF_ALG is now blocked in the default seccomp profile — verify custom profiles

  The default seccomp policy now blocks the AF_ALG (kernel crypto) socket family. Containers relying on AF_ALG for hardware crypto offloading will break after this upgrade. Audit your workloads — most standard containers won't be affected, but custom crypto or HSM-adjacent workloads might. If needed, override via a custom seccomp profile rather than relaxing the default.

• breakingOut-of-range USER values now fail explicitly — check your container images

  Previously, an out-of-range UID/GID in the OCI spec could silently trigger name lookups with unpredictable results. Now containerd returns an error. If you have images or specs with numeric USER values outside valid range, containers will fail to start instead of behaving unexpectedly. Run a pre-upgrade check on your image inventory, especially anything using high numeric UIDs.

• enhancementAppArmor < 3.0 compatibility restored — relevant for older distros

  If you're running containerd on Ubuntu 20.04, Debian Bullseye, or any distro shipping AppArmor 2.x, earlier 1.7.x releases may have caused AppArmor profile load failures. This fix conditionally omits the abi directive. Upgrade and verify AppArmor profile loading if you've been seeing related errors.

containerd 2.3.1 patches CVE-2026-46680 and fixes several runtime/snapshotter bugs including seccomp hardening that blocks AF_ALG sockets by default.

• securityPatch CVE-2026-46680 now — upgrade from 2.3.0

  CVE-2026-46680 is fixed in this release. Details are in the containerd security advisory. If you're on 2.3.0, treat this as a mandatory upgrade. Check your package manager or deployment pipeline to roll out 2.3.1 across all nodes before the vulnerability details are widely circulated.

• securityAF_ALG blocked in default seccomp policy — test workloads that use kernel crypto

  The default seccomp profile now blocks AF_ALG (Linux kernel crypto API via sockets). Most containerized applications won't touch this, but anything using AF_ALG directly for cryptographic operations will break. Before upgrading in production, verify your workloads don't rely on AF_ALG — run a quick strace or audit your application's socket calls. Custom seccomp profiles are unaffected.

• breakingNon-runc runtime users: test sandbox task API behavior after upgrade

  The sandbox task API endpoint fix and deprecation of task fields in Runc options targets non-runc runtime setups (e.g., Kata Containers, gVisor). If your cluster uses alternative runtimes, validate that container creation and task management still work as expected post-upgrade. The deprecation of task fields means you should audit any custom Runc options configs to remove deprecated fields before they're removed in a future version.

containerd API v1.11.0 ships a new shim bootstrap protocol, container filesystem copy transfer types, and sandbox spec field support — aligning with the containerd 2.3 runtime release.

• securitygRPC updated from v1.59.0 to v1.79.3 — multiple CVE fixes included

  A 20-minor-version jump in gRPC covers a significant span of security and stability fixes. If your environment pins or vendors gRPC separately, reconcile your dependency tree against v1.79.3. The golang.org/x/* packages also moved forward across the board, so a full dependency audit is warranted before deploying this API version in production.

• breakingSandbox API: Container field removed, update any sandbox metadata consumers

  The Container field has been dropped from sandbox metadata and replaced with a spec field. If you have tooling, controllers, or custom runtimes that read or write sandbox metadata directly, audit them now. This is an API-level change — anything compiled against the old proto definitions will break at runtime when targeting containerd 2.3.

• breakingShim bootstrap protocol is now protobuf — custom shim implementations need updating

  The new shim bootstrap protocol switches from JSON to protobuf and uses enums instead of strings for capabilities and log levels. If you maintain a custom shim or vendor the containerd API, you must update your bootstrap handling before deploying containerd 2.3. Third-party shims (e.g., kata-containers, nydus) likely need corresponding releases — check their compatibility before upgrading.

containerd v2.2.3 patches CVE-2026-35469 in spdystream and fixes several bugs including whiteout handling in parallel unpacks, TOCTOU race in tar extraction, and Go 1.24 symlink regressions.

• securityPatch CVE-2026-35469: upgrade to v2.2.3 now

  CVE-2026-35469 affects moby/spdystream, which containerd uses for streaming connections. The fix is in spdystream v0.5.1, bundled in this release. If you're running any 2.2.x version, treat this as a mandatory upgrade — don't wait for your next maintenance window.

• breakingParallel unpack whiteout bug could mean corrupted layer state — verify images

  A bug caused whiteout files (which signal file deletions between layers) to be ignored when parallel unpack was enabled. If you've been using parallel unpack with overlayfs, layer deletion semantics may not have applied correctly. After upgrading, re-pull any images that were unpacked in parallel to ensure their layer state is consistent.

• enhancementGo 1.24 users on NixOS or symlink-heavy rootfs: this fixes your container startup failures

  Absolute symlink handling in rootfs user/group lookups regressed with Go 1.24. This affected systems where /etc/passwd or /etc/group are symlinks (common on NixOS-style setups). If you've seen user lookup failures or container start errors after moving to Go 1.24-built binaries, upgrading to v2.2.3 resolves this.

containerd 2.0.8 patches CVE-2026-35469 in spdystream, fixes a credential leak in CRI error messages, and resolves a CNI DEL lifecycle bug after containerd restarts.

• securityPatch CVE-2026-35469 by upgrading to 2.0.8 now

  CVE-2026-35469 lives in the moby/spdystream dependency. Details are in a GitHub security advisory. If you're running containerd 2.0.x in any cluster, upgrade to 2.0.8 — this is the primary reason for the release. Don't wait for your next maintenance window if the advisory turns out to be high severity.

• securityCheck your pod event logs for past credential exposure

  Before this fix, registry credentials or other secrets embedded in URLs could appear in plaintext inside CRI gRPC error messages and pod events. If you're shipping pod events to a logging backend (Datadog, Splunk, ELK, etc.), audit recent logs for query parameters that shouldn't be there. Going forward, 2.0.8 redacts these before they leave containerd.

• breakingValidate CNI network cleanup works correctly after upgrading

  The CNI DEL bug meant network namespaces and CNI plugin state weren't cleaned up when a pod was deleted after a containerd restart. This could leave stale network state on nodes. After upgrading to 2.0.8, verify that pod deletion properly invokes CNI DEL — especially on nodes that have experienced containerd restarts. If you've noticed orphaned network interfaces or IP allocation issues, this fix is the likely culprit.

containerd 2.1.7 patches CVE-2026-35469 in spdystream and ships several hardening fixes including credential leak prevention via gRPC and a TOCTOU race in tar extraction.

• securityPatch CVE-2026-35469 by upgrading to 2.1.7 now

  CVE-2026-35469 in moby/spdystream is fixed in this release. spdystream is used in the CRI streaming path, so any cluster running Kubernetes workloads with exec/attach/port-forward is potentially exposed. Upgrade containerd to 2.1.7 on all nodes. No config changes needed, just a binary swap and daemon restart.

• securityCredential leak via gRPC pod events is now closed

  Before this fix, raw errors containing registry credentials could surface in pod events visible to namespace-scoped users. If your clusters allow broad pod event access, assume credentials may have been exposed in logs or event streams. Rotate any registry pull secrets used on affected clusters, then upgrade to 2.1.7 to prevent recurrence.

• enhancementCNI DEL fix prevents IP/resource leaks after restarts

  A bug meant CNI DEL was never called for sandboxes cleaned up after a containerd restart, leaking network resources. If you've seen stale IPs or CNI state after node restarts, this is likely why. Upgrade to 2.1.7 and consider draining nodes before restarting containerd to clear any existing leaked state.

v1.7.31 patches CVE-2026-35469 in spdystream, fixes a CNI DEL regression after restarts, and closes a credential leak in pod events via gRPC error sanitization.

• securityPatch CVE-2026-35469 by upgrading to v1.7.31 now

  CVE-2026-35469 affects the moby/spdystream library used for SPDY multiplexing. The fix is in spdystream v0.5.1, bundled here. If you're running any 1.7.x release prior to this, upgrade immediately — especially on clusters where the CRI streaming server is exposed or where kubectl exec/attach/port-forward traffic flows through containerd.

• securityAudit pod event logs for previously leaked credentials

  A bug caused raw error messages — potentially containing registry credentials — to be returned over gRPC and surface in pod events. After upgrading, review historical pod event logs (kubectl get events, or your log aggregation system) for any entries containing auth tokens, passwords, or image pull secrets from before this fix was applied. Rotate any credentials you find.

• breakingVerify CNI network teardown is working correctly after upgrade

  The CNI DEL fix means containers that previously left behind stale network state after a containerd restart will now properly clean up. This is the right behavior, but if you have automation or scripts that assumed CNI DEL was idempotent-by-absence (i.e., expected cleanup to be skipped), test those workflows. Nodes with a history of unclean restarts may see cleanup activity on first pod deletion post-upgrade.

containerd 2.2.2 fixes critical CRI networking bugs, registry credential leakage, and AppArmor compatibility issues that could affect production Kubernetes workloads.

• securityUpdate to prevent registry credential exposure

  Registry credentials could leak in error messages and pod events. Deploy this patch immediately if you use private registries with authentication, as these credentials might appear in logs or Kubernetes events that could be accessed by unauthorized users.

• breakingFix CNI network cleanup after restarts

  CNI DEL operations weren't executing after containerd restarts, leaving stale network configurations. This affects pod networking reliability. Update before your next maintenance window to prevent network namespace leaks and potential IP conflicts.

• enhancementUpgrade for AppArmor compatibility

  AppArmor profiles now work correctly with unix domain sockets on modern kernels. If you're running newer kernel versions and experiencing socket connection issues with AppArmor enabled, this update resolves the compatibility problem.