リリース

日本語 準備中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.

日本語 準備中Patch release fixing sandbox task API endpoints broken for non-runc shims — critical for anyone running alternative runtimes like Kata Containers or gVisor.

• breakingUpgrade if you run non-runc runtimes in sandbox mode

  The bug in api/v1.11.0 caused sandbox task API endpoints to malfunction for any shim that isn't runc — think Kata Containers, gVisor, or custom shims. If your cluster uses these runtimes and you're on 1.11.0, task operations against sandboxed workloads may silently fail or misbehave. Update to api/v1.11.1 immediately and verify task lifecycle operations (create, delete, exec) work correctly post-upgrade.

• enhancementValidate your shim compatibility after upgrading

  The fix adds the task API address to CreateTaskRequest at the proto level. If you maintain a custom shim, review whether your implementation reads this field — it's now populated where it wasn't before. No action needed for standard runc workloads, but non-standard shim authors should test task creation flows against this API version.

日本語 準備中Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.

• securityUpgrade immediately to patch OpenTelemetry CVEs

  OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.

• breakingPlan your Helm v4 migration — v3 EOL is real

  The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.

• enhancementTest OCI index-based chart pulls if you use multi-arch registries

  The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.

日本語 準備中Helm v4.2.0 ships Kubernetes 1.36 client support, a new mustToToml template function, fixes for dry-run server mode with generateName, and several post-renderer YAML parsing correctness fixes.

• breakingRemove --hide-notes and --render-subchart-notes from your CI scripts

  Both flags are now deprecated and will likely be removed in a future release. Audit your helm install/upgrade/template invocations in CI pipelines and scripts. Dropping them now avoids a forced migration later when they're removed entirely.

• enhancementAdopt mustToToml for safer TOML templating

  The new mustToToml function behaves like mustToJson — it returns an error instead of silently failing when TOML serialization goes wrong. If you're using toToml anywhere in your chart templates, swap it for mustToToml so template rendering failures are surfaced as actual errors rather than empty or malformed output.

• enhancementValidate --dry-run=server against generateName resources

  Previously, --dry-run=server skipped resources that used generateName instead of name, which gave false confidence that those resources were being validated. That's fixed now. Re-run your server-side dry-run checks against any charts that use generateName — you may catch validation errors that were previously being silently ignored.

日本語 準備中Kubernetes v1.36.1 is a focused patch release fixing 8 bugs across networking, node, and cluster lifecycle — most impacting Windows environments, ZFS nodes, and kubeadm-managed clusters.

• breakingZFS nodes: upgrade immediately if running v1.36.0

  kubelet fails to start on ZFS-backed nodes in v1.36.0 due to a missing cadvisor plugin. If you deployed v1.36.0 on ZFS storage, those nodes are likely not running. Patch to v1.36.1 before any further ZFS node rollouts.

• breakingWindows L2Bridge users: DNS timeouts are fixed but require upgrade

  Stale HNS endpoints caused traffic to route to wrong nodes when pod IPs were reused, producing silent DNS failures. This is hard to diagnose and easy to misattribute to DNS config. If you run Windows nodes with L2Bridge networking, treat this as a high-priority patch.

• enhancementkubeadm bootstrap is more resilient against slow load balancers

  Previously, kubeadm init could fail or behave unexpectedly when the control plane load balancer wasn't ready yet. The fix makes bootstrap use the local API endpoint first, then defer to the LB endpoint — a meaningful improvement for cloud environments where the LB provisions asynchronously. Worth upgrading before your next cluster init or upgrade cycle.

日本語 準備中Kubernetes v1.35.5 is a focused patch release fixing scheduler state corruption, Windows networking, kube-proxy large-cluster behavior, and several kubeadm initialization issues.

• breakingKubeadm users: review kubeconfig generation behavior after upgrade

  The kubeadm init change to use localAPIEndpoint for admin.conf and super-admin.conf is a behavioral fix, but clusters with custom controlPlaneEndpoint setups should validate that kubeconfigs are generated correctly after upgrading. If you rely on the controlPlaneEndpoint in generated configs for post-init tooling, test in staging first.

• enhancementLarge clusters: upgrade kube-proxy to stop unnecessary full-syncs

  If you're running 1000+ endpoints, kube-proxy was previously triggering full-sync operations it shouldn't. This patch stops that. The fix directly reduces CPU and network overhead on busy clusters — upgrade kube-proxy as part of your next maintenance window.

• enhancementScheduler memory leak fix — prioritize this patch if you see scheduling instability

  The scheduler bug with in-flight state tracking could cause unbounded growth in memory usage when pods with reused names fail scheduling repeatedly. If you've observed scheduling delays or growing scheduler memory consumption, this patch addresses the root cause directly.

日本語 準備中v1.34.8 is a focused bug-fix patch addressing IPv6 CIDR allocation errors, a scheduler memory leak, Windows DNS routing failures, and several kubeadm cluster lifecycle issues.

• securitykubeadm now uses a dedicated ClusterRole for kube-apiserver kubelet access

  The kube-apiserver's kubelet client is now bound to 'system:kubelet-api-admin' instead of a shared role. For kubeadm-managed clusters, re-running 'kubeadm init phase bootstrap-token' or upgrading via kubeadm will apply this change. Existing clusters upgraded in-place will get this tighter RBAC scoping automatically — verify with 'kubectl get clusterrolebinding' post-upgrade.

• breakingIPv6 clusters: audit ServiceCIDR allocations before upgrading

  The 64-bit IPv6 ServiceCIDR bug means some clusters may have services with IPs that technically fall outside the configured subnet. After upgrading to v1.34.8, check whether any existing service IPs are out-of-range and consider recreating affected services. This primarily impacts clusters using /64 IPv6 service CIDRs.

• enhancementLarge clusters: kube-proxy full-sync elimination reduces control plane pressure

  If you're running clusters with 1000+ endpoints, kube-proxy was performing expensive full-sync operations unnecessarily in large-cluster mode. This patch stops that. The benefit is lower CPU and latency spikes during endpoint churn. No config changes needed — upgrade and monitor kube-proxy CPU usage to confirm the improvement.

日本語 準備中v1.33.12 is a focused patch release with four kubeadm bug fixes targeting cluster init reliability, etcd health checks, and RBAC hardening for kubelet API access.

• securityRBAC isolation for kube-apiserver's kubelet client is now enforced

  The kube-apiserver now uses a dedicated ClusterRole 'system:kubelet-api-admin' for its kubelet client credentials. This tightens RBAC boundaries and reduces blast radius if credentials are ever misused. No immediate action required for existing clusters, but verify your RBAC audits reflect this role after upgrading kubeadm.

• enhancementUpgrade kubeadm if you use external load balancers during cluster init

  Previously, kubeadm init would write kubeconfigs pointing at the load balancer endpoint, which fails when the LB isn't provisioned until after the first apiserver starts — a chicken-and-egg problem common with cloud providers. The fix makes init use the local API endpoint instead. If you've been working around this with retry scripts or manual kubeconfig edits, this patch removes the need for those hacks.

• enhancementEtcd quorum-based health check prevents false failures in partially degraded clusters

  The old all-members health check would fail kubeadm operations if any etcd member was unhealthy, even when quorum was maintained. Now it only blocks when quorum is actually lost. If you run 3- or 5-node etcd clusters and have hit spurious kubeadm upgrade or join failures due to a single unhealthy member, this patch resolves that.

日本語 準備中CRI-O v1.36.0 ships CNI health monitoring, configurable GOMAXPROCS injection, TLS hardening options, and a CVE fix — alongside a batch of race condition and cgroupv2 bug fixes.

• securityPatch CVE-2026-35469 by upgrading to v1.36.0

  The spdystream dependency carried CVE-2026-35469. If you're running v1.35.x, this is a direct reason to upgrade. After upgrading, verify the release bundle with cosign against the signed bundle artifacts — the SLSA provenance and OpenVEX report are both available for this release.

• breakingValidate CNI plugin behavior under new continuous health monitoring

  CRI-O now polls CNI plugins with STATUS after initial readiness. A plugin that was silently degraded will now actively set NetworkReady=false on the node, blocking pod scheduling. Before upgrading, confirm your CNI plugin properly implements the STATUS verb (Cilium, Calico, and Flannel do; older or custom plugins may not). Test in a non-production cluster first — this is a behavioral change that could surface latent CNI issues.

• enhancementSet TLS minimums for the CRI-O API — don't leave defaults in production

  New `tls_min_version` and `tls_cipher_suites` options under `[crio.api]` let you enforce TLS 1.2+ and restrict weak cipher suites on the streaming and metrics endpoints. The default is TLS 1.2, but you should explicitly set `tls_min_version = TLS13` in security-sensitive environments and review your cipher suite policy. Update your configuration management (Ansible, SaltStack, etc.) to codify this before the next node rollout.

日本語 準備中v1.35.3 patches CVE-2026-35469, fixes a container stop panic and exit-code race, adds CNI health monitoring (then reverts it), and introduces GOMAXPROCS floor injection for containers.

• securityPatch CVE-2026-35469 by upgrading to v1.35.3

  The spdystream dependency had a vulnerability (CVE-2026-35469) fixed by bumping to moby/spdystream v0.5.1. If you're running v1.35.x, upgrade to v1.35.3 now. There's no workaround — the fix is only in the updated binary.

• breakingCNI health monitoring was added and then reverted in the same release

  CRI-O briefly added continuous CNI plugin health checks using the STATUS verb, which would have marked nodes NetworkReady=false on plugin failures. It was reverted before this release shipped because it caused bootstrapping regressions. Net result: no behavior change for CNI in v1.35.3. But if you saw this feature in changelogs and planned for it, don't — it's gone and will likely return in a future release with fixes.

• enhancementUse 'min_injected_gomaxprocs' to prevent CPU underutilization in containers with low CPU requests

  Containers with very low cpu.request values can end up with GOMAXPROCS=1, throttling Go-based workloads. The new 'min_injected_gomaxprocs' config field sets a floor so CRI-O injects max(floor, cpu.request) as GOMAXPROCS. This is particularly useful for Go-based sidecars or agents that are request-constrained but need threading headroom. Set this in your CRI-O config if you run Go workloads with conservative CPU requests.

日本語 準備中CRI-O v1.34.8 patches CVE-2026-35469 in the spdystream dependency and adds two operator-facing features: a new runtime metric and configurable GOMAXPROCS injection.

• securityPatch CVE-2026-35469 — update to v1.34.8 now

  The spdystream library had a vulnerability fixed in this release. spdystream is used for streaming connections (exec, attach, port-forward), so exposure is real in any cluster. Upgrade CRI-O to v1.34.8 on all nodes. No config changes required — the fix is purely a dependency bump.

• enhancementUse the new runtime metric to audit node configurations

  The `container_runtime_crio_default_runtime` metric lets you confirm — via your existing Prometheus stack — that every node is actually running the runtime you expect (e.g., runc vs. kata-containers). This is particularly useful in mixed-runtime clusters or after node image upgrades where config drift can go undetected. Add an alert for unexpected runtime values once you've upgraded.

• enhancementEvaluate min_injected_gomaxprocs for CPU-constrained workloads

  If you run containers with very low cpu.request values (e.g., 0.1 cores), Go runtimes default to GOMAXPROCS=1, which can serialize work that should be parallel. Setting `min_injected_gomaxprocs` raises the floor so those containers get a more reasonable thread count. Be cautious on dense nodes: raising GOMAXPROCS across all containers increases goroutine scheduling overhead. Test with a non-Guaranteed workload first and watch CPU throttling metrics before rolling out cluster-wide.

日本語 準備中v1.33.12 patches CVE-2026-35469 via a spdystream dependency bump and adds a new min_injected_gomaxprocs option for controlling GOMAXPROCS floor in containers.

• securityPatch CVE-2026-35469 — upgrade now

  The spdystream dependency update addresses CVE-2026-35469. Since spdystream handles HTTP/2 multiplexing in CRI-O's communication paths, any cluster running v1.33.x should move to v1.33.12 promptly. Check your vulnerability scanner results for this CVE and treat this as a routine security patch cycle rather than waiting for your next maintenance window.

• enhancementUse min_injected_gomaxprocs to prevent CPU underutilization in Go workloads

  Go runtimes default GOMAXPROCS to the number of logical CPUs on the node, which causes goroutine scheduling inefficiency when containers have small cpu.request values. This new option lets you set a floor (e.g., 2 or 4) so containers don't get starved of OS threads. It only applies to Burstable and BestEffort pods — Guaranteed QoS pods and partitioned workloads are unaffected. Start by auditing Go-based workloads in your cluster that run with low cpu.request; set min_injected_gomaxprocs conservatively and monitor goroutine behavior before widening the floor.

日本語 準備中etcd v3.6.11 is a patch release. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingRead the upgrade guide before patching

  The release explicitly warns of potential breaking changes in the 3.6 upgrade path. Don't treat this as a routine patch drop — pull the CHANGELOG-3.6.md and the upgrade guide, diff against your current version, and validate in a non-prod cluster first.

• enhancementVerify container registry source in your pipelines

  etcd's primary registry is gcr.io, not Docker Hub or quay.io. If your CI/CD or Kubernetes manifests still pin quay.io/coreos/etcd, you're on the secondary mirror which may lag. Update image references to gcr.io/etcd-development/etcd to stay on the canonical source.

日本語 準備中etcd v3.5.30 is a maintenance release in the 3.5 series. No release notes were published beyond pointers to the full changelog — check the CHANGELOG-3.5.md directly for specifics.

• breakingRead the full CHANGELOG before upgrading

  The release announcement is intentionally sparse — it just points to CHANGELOG-3.5.md. Before upgrading any etcd cluster, pull up that changelog directly and review every entry since your current version. etcd upgrades in production clusters carry real risk; skipping the changelog review is how you get surprised by behavior changes or data format shifts.

• enhancementStick to gcr.io as your primary image source

  The release explicitly lists gcr.io/etcd-development/etcd as primary and quay.io/coreos/etcd as secondary. If your deployment pipelines or air-gapped mirrors are still defaulting to quay.io, consider updating them to match the project's own priority — gcr.io tends to get images published first.

日本語 準備中etcd v3.4.44 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for the actual fix list before upgrading.

• breakingReview CHANGELOG before upgrading — release notes are empty

  The published release notes contain no change summary. Before upgrading any production cluster, pull up CHANGELOG-3.4.md directly and diff against your current version. Skipping this step on a Kubernetes control plane means you could hit an undocumented behavioral change mid-upgrade.

• enhancementStill on 3.4? Evaluate migration to 3.5

  3.4.x receives only critical fixes at this point. If you're running etcd as a Kubernetes backing store, now is a good time to plan a move to 3.5, which has a longer active support runway. Check Kubernetes version compatibility before scheduling the upgrade.