On May 20, all four active containerd release branches shipped security patches on the same day. Versions 2.3.1, 2.2.4, 2.0.9, and 1.7.32 all landed within hours of each other. That pattern has one name: coordinated security release.
The CVE being addressed is CVE-2026-46680. The advisories do not detail exploitability yet, which is standard for coordinated disclosures. The simultaneous four-branch patch is the signal that matters here.
What changed in each version
All four releases include the same core hardening:
AF_ALG blocked in default seccomp profile. The kernel crypto API socket family (AF_ALG) is now blocked by default. This syscall family has appeared in privilege escalation chains before -- removing access from the default profile reduces the attack surface without affecting workloads that don't explicitly need it.
Out-of-range USER values in OCI specs fixed. Handling of invalid USER fields was corrected to prevent unexpected username and group lookups. Malformed OCI specs with out-of-range values could previously trigger behaviour that bypassed intended identity handling.
Overlayfs rebase disabled in user namespaces. The overlayfs "rebase" capability is now disabled when running inside user namespaces, closing a potential privilege escalation vector in rootless container setups.
AppArmor ABI conditional for versions before 3.0 (1.7.32 only). The 1.7.32 release also makes AppArmor ABI settings conditional on AppArmor version, fixing compatibility on systems running AppArmor older than 3.0.
CVE-2026-34986 in go-jose (2.2.4 only). The 2.2.x branch also patches CVE-2026-34986 in the go-jose JSON Object Signing and Encryption library. If you run 2.2.x, you have two CVEs to account for in this update.
Which version to get
| Branch | Patched version |
|---|---|
| 2.3.x | 2.3.1 |
| 2.2.x | 2.2.4 |
| 2.0.x | 2.0.9 |
| 1.7.x | 1.7.32 |
The 1.7.x branch is the oldest one still receiving patches. If you are running it, 1.7.32 is what you need today, but you should be planning a migration to 2.x.
How to update
On most Kubernetes nodes, updating containerd means draining the node first, then updating the package, then returning it to the pool.
# Verify what you're running
containerd --version
# On Debian/Ubuntu
apt-get update && apt-get install containerd.io
# On RHEL/Rocky/AlmaLinux
dnf update containerd.ioFor managed distributions:
- k3s / RKE2: These bundle their own containerd binary. Wait for a patched release from Rancher or update the embedded binary per node.
- EKS / GKE / AKS: Cloud providers typically lag a few days. Check the managed node pool release notes.
- Docker Desktop: Expect an update from Docker Inc. Check for application updates.
What to verify after updating
Check that the seccomp profile on running containers reflects the updated policy. For workloads using AF_ALG explicitly (hardware crypto offload, some HSM integrations), test in a staging environment before rolling to production. The change is a default profile change, not a kernel change -- workloads that need AF_ALG can still add it back via a custom seccomp profile.
For more on container image scanning after runtime updates, see Trivy 0.70.0: post-incident, one silent CI break.
Sources: containerd v2.3.1; containerd v2.2.4; containerd v2.0.9; containerd v1.7.32