リリース

日本語 準備中Helm v3.21.2 updates Kubernetes client libraries to match v1.36. This is a routine patch for client library alignment; upgrade to stay compatible with Kubernetes v1.36 clusters.

• enhancementUpdate to v1.21.2 if you run Kubernetes v1.36

  Helm v3.21.2 updates its Kubernetes client libraries (client-go) to match the v1.36 API. If you already run Kubernetes v1.36 clusters, upgrade Helm to v3.21.2 to ensure full compatibility and avoid potential client-server version skew issues. Teams on earlier Kubernetes versions are not blocked — the upgrade is optional but recommended for consistency.

日本語 準備中Lima v2.1.3 is a security-focused patch release fixing two CVEs: a privilege escalation in QEMU VMs and multiple containerd CVEs bundled via nerdctl v2.3.3. Upgrade promptly.

• securityPatch QEMU privilege escalation (CVE-2026-53657) immediately

  Any unprivileged user inside a QEMU-backed Lima VM could gain root inside that VM by abusing the guest agent socket. If you share Lima VMs among multiple users or run untrusted workloads, this is high priority. Upgrade to v2.1.3 and restart affected VMs.

• securitycontainerd CVE batch via nerdctl v2.3.3 — upgrade required

  Five CVEs in containerd are fixed in the bundled nerdctl v2.3.3 (containerd v2.3.2). If your Lima instances run container workloads, the old containerd is exposed. Upgrade Lima and recreate or restart VMs to pick up the new nerdctl binary.

• breakingcontainerd.user defaults changed for non-Linux guests

  Lima no longer sets containerd.user=true by default on non-Linux guests (macOS, Windows). If you relied on rootless containerd on those platforms without explicitly setting this, validate your VM config after upgrading and set containerd.user=true explicitly if needed.

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

日本語 準備中Helm v4.2.2 reverts a premature exit fix in WaitForDelete that was causing test failures. A one-line patch addressing a race condition in status observation.

• breakingWaitForDelete race condition re-introduced—test suite hangs may return

  The patch that fixed a race condition in WaitForDelete (where the status observer canceled the watch too early) has been reverted in v4.2.2. If you run comprehensive Helm test suites or rely on WaitForDelete behavior, you may see intermittent hangs or timeouts again. Monitor test runs for flakiness after upgrading. A proper fix is likely incoming in a future patch—do not stay on v4.2.2 longer than necessary.

日本語 準備中Helm v4.2.1 fixes data races in concurrent operations, corrects output routing for command messages, and resolves version constraint parsing issues that caused false negatives.

• breakingVerify output parsing in automation after upgrade

  Helm command success messages now correctly write to stdout instead of stderr. If your CI/CD pipelines, monitoring, or shell scripts redirect or filter Helm output by stream, they may behave unexpectedly. Check any grep, tee, or output capture logic that assumes helm writes to stderr. Most scripts should work unchanged, but streaming-dependent logic needs review.

• enhancementUse version range constraints without workarounds

  Helm 4 previously rejected or warned about valid version range constraints like prerelease versions and missing spaces (e.g., 'v1.0.0||v1.1.0'). This is now fixed. If you've avoided version ranges or used pinned versions as a workaround, you can now adopt constraint-based version selection, which simplifies dependency management in large deployments.

• enhancementUpgrade to get concurrent operation stability

  Multiple race conditions in concurrent goroutines (upgrade + rollback, install + uninstall on the same client, and WaitForDelete timing) are now fixed. Teams running high-concurrency Helm operations (e.g., multi-chart deployments, parallel reconciliation loops, or large test suites) should upgrade to eliminate intermittent failures. This is particularly important if you see flaky test results in your CI pipeline.

日本語 準備中Helm v3.21.1 fixes a nil pointer panic in template operations and updates dependencies. A straightforward patch for stability.

• securityUpgrade for Go security patch GO-2026-5026

  golang.org/x/net was bumped to v0.55.0 to fix GO-2026-5026. This is a supply-chain dependency, not directly exposed in Helm's API. Upgrade if your security scanning flags net vulnerabilities. No action needed if you're just using Helm normally—the fix is built in.

• breakingClientOnly template operations now error correctly instead of panicking

  Helm template commands executed without cluster access (ClientOnly mode) previously crashed with nil pointer panics. v3.21.1 returns proper template errors instead. If you have automation that catches panics, update error handling to expect typed template errors. Test your template workflows before production rollout.

• enhancementRegistry credentials now persist through HTTP fallback

  Registry operations now keep credentials when falling back from HTTPS to plain HTTP, thanks to oras-go v2.6.1. If you use private registries with HTTP-only endpoints, this improves reliability. No configuration change needed; the fix is automatic.

日本語 準備中Kubernetes v1.36.2 is a patch release fixing critical bugs in Dynamic Resource Allocation (DRA) scheduler, CSI volume republishing, and endpoint controller, plus a Go 1.26.4 build update.

• securityBinary non-UTF8 Secret data in container env vars now handled correctly

  Kubernetes 1.34+ had a regression where containers could not properly read environment variables set from Secret API objects containing binary non-UTF8 data. This is fixed in 1.36.2. If your workloads use non-text Secret data in environment variables, upgrade to prevent decode errors or silent failures.

• breakingDRA device allocation bug affects multi-device workloads

  Kubernetes 1.36.0–1.36.1 has a scheduler bug that assigns mutually exclusive device partitions to multiple Pods when drivers use SharedCounters with multi-allocatable devices. This can cause workload failures, device conflicts, crashes, or data loss. If you use DRA with multi-allocatable devices (especially GPUs or custom accelerators with shared counters), upgrade to 1.36.2 immediately. Review recent Pod scheduling decisions for conflicts.

• enhancementCSI volume republish failures no longer corrupt mount state

  Kubelet was incorrectly deleting CSI mount directories when periodic NodePublishVolume calls (triggered by requiresRepublish=true) failed, leaving pods with stale volume content. This is fixed in 1.36.2. If you run CSI drivers with requiresRepublish=true, this patch eliminates a data consistency risk—upgrade to prevent potential data issues on transient network or storage errors.

日本語 準備中Kubernetes v1.35.6 fixes critical issues in pod scheduling with multi-node claims, DRA device selection, CSI volume republishing, and endpoint handling; includes a Go runtime upgrade and performance improvements.

• securitySecret binary data in environment variables now handled correctly

  A 1.34+ regression broke environment variable injection from Secrets containing non-UTF8 binary data (e.g., certificates, keys in base64-encoded Secrets). If you inject Secrets as env vars and those Secrets contain binary data, upgrade to v1.35.6. Test this quickly if you run database credentials or keys via Secrets—the bug may have silently broken injection.

• breakingUpgrade Go runtime to 1.25.11 in your build pipeline

  Kubernetes v1.35.6 is built with Go 1.25.11. If you run custom controllers or operators on the same Go version, verify compatibility and rebuild. If your CI/CD locks Go versions, update your build configuration. This is standard but must be done; old Go versions may have security gaps you're inheriting.

• enhancementDRA scheduling and CSI republishing now reliable for dynamic resource allocation

  Three bugs are fixed: (1) scheduler no longer panics on DRA ResourceClaim with AllocationMode All and shared counters; (2) pods using multi-node and per-node claims no longer deadlock in Pending; (3) kubelet no longer deletes CSI mount directories on transient NodePublishVolume errors, preventing stale volume data. If you use DRA (dynamic resource allocation) or CSI with republish enabled, this release eliminates previously deadlocking scenarios. Upgrade to clear stuck pods and prevent future hangs.

日本語 準備中Kubernetes v1.34.9 fixes volume handling in CSI mounts, binary secret data in containers, endpoint controller panics, and kubeadm certificate handling. Go 1.25.11 build improves runtime performance.

• breakingUpgrade kubelet if running CSI drivers with requiresRepublish enabled

  A 1.34+ regression caused kubelet to delete CSI mount directories on republish failures, stranding pods with stale volume data. If you run CSI drivers with spec.requiresRepublish=true, upgrade immediately. Check your CSI driver specs and watch for failed republish attempts in kubelet logs before upgrading to confirm you hit this bug.

• breakingTest binary Secret injection in container environment variables

  v1.34 broke environment variable parsing for containers referencing Secrets with binary (non-UTF8) data. If your workloads inject Secret data into environment variables, test them after upgrading. Check application startup logs for parsing errors; you may need to base64-encode binary Secret values instead.

• enhancementUpdate Go runtime for performance and security

  v1.34.9 uses Go 1.25.11, which includes runtime optimizations and security patches. Upgrade when you next rotate your control plane and worker nodes. No code changes needed on your side, but the Go update may improve latency and reduce memory usage in your cluster.

日本語 準備中CoreDNS v1.14.4 delivers a broad set of targeted fixes and new capabilities: DNSSEC signing correctness fix, cache behavior improvements, forward plugin now resolves hostnames, and several transport security hardening items.

• breakingDNSSEC signing behavior changed — review delegated zone setups

  The fix to sign each RRset with its owning zone rather than the query zone is technically correct, but if you have multi-zone DNSSEC setups with delegations, validate your signed responses after upgrading. Zones that were relying on the previous (incorrect) signing behavior may produce different signatures. Run dnssec-verify on a sample of records before cutting over in production.

• enhancementUse hostname-based forward targets instead of hard-coded IPs

  The forward plugin now resolves hostnames for TO endpoints at runtime. If your CoreDNS configs currently pin upstream resolver IPs, you can switch to FQDNs and let CoreDNS handle resolution. This simplifies config management in environments where upstream IPs change (e.g., cloud-managed resolvers). Test in staging first — resolution failures at startup could affect forwarding.

• enhancementRemove the 3600s cache TTL ceiling if longer TTLs are appropriate

  Cache TTLs were previously capped at 3600s regardless of the DNS record's actual TTL. That cap is gone. For stable records (root hints, internal authoritative zones) you can now set higher max_ttl values to reduce upstream query load. Audit your cache plugin config and raise max_ttl where it makes sense.

日本語 準備中CRI-O v1.35.4 is a patch release with no code changes or dependency updates from v1.35.3 — essentially a rebuild or re-tag of the previous patch.

• enhancementSkip this upgrade unless you need a clean rebuild

  There are zero changelog entries and zero dependency changes. This release is likely a rebuild triggered by a CI/pipeline issue or a signing/artifact correction. If you're already on v1.35.3 and it's working, there's no functional reason to upgrade. Check the CRI-O GitHub issue tracker or release PR for context on why this tag was cut before deciding to roll it out.

• enhancementVerify artifact integrity with cosign and SBOM before deploying

  Even for a no-change release, practice your supply chain verification workflow: use cosign to verify the signature on the tarball and the bom tool to validate the SPDX SBOM. This is good hygiene to establish before you need it on a critical release.

日本語 準備中CRI-O v1.36.1 is a small patch fixing a container status regression where ImageRef flipped to a raw image ID after restart, plus a debug log verbosity reduction.

• breakingUpgrade if you rely on ImageRef for image identity after restarts

  Before this fix, CRI-O restarts caused ImageRef in container status to switch from a repo@digest string to a raw image ID. Any tooling that parses ImageRef — admission controllers, audit pipelines, image policy enforcers — could silently receive the wrong format and fail validation or produce incorrect audit records. If you run workloads where CRI-O restarts are common (e.g., upgrades, node reboots), patch to v1.36.1 immediately and validate your tooling handles the repo@digest format consistently.

• enhancementExpect quieter debug logs under high-frequency List* RPC calls

  Clusters with aggressive monitoring or reconciliation loops generating frequent ListContainers/ListPodSandboxes calls were generating excessive debug log volume, which hurt CRI-O performance under high load. After this patch, debug logging is less chatty for these paths. If you previously reduced log levels specifically to work around this noise, you can now safely re-enable debug logging without the same overhead.

日本語 準備中CRI-O v1.34.9 fixes two concurrency bugs: a panic from racing StopContainer calls and a spurious exit code 255 on fast-exiting containers. Pure bug-fix release, no dependency changes.

• breakingPanic risk on concurrent StopContainer — upgrade if you drain nodes or run rapid pod teardowns

  If your cluster drains nodes, runs batch workloads with rapid pod churn, or uses any automation that issues multiple StopContainer calls in parallel, the pre-fix versions could panic CRI-O, taking down the container runtime on that node. This is a hard crash, not a graceful error. Upgrade to v1.34.9 immediately on any node where concurrent stop operations are plausible.

• enhancementExit code 255 false positives are gone — review alerting and restart policies

  Exit code 255 is often treated as a runtime-level failure in monitoring stacks and can trigger unnecessary pod restarts or alerts. If you have OOMKill or fast-exit workloads (init containers, short-lived jobs) and have seen spurious 255 exit codes in your logs or metrics, those were false positives from this race. After upgrading, audit your alerting rules and CrashLoopBackOff history — you may find some pods were incorrectly flagged.

日本語 準備中Single-fix patch release resolving a race condition that caused CRI-O to incorrectly report exit code 255 for fast-exiting containers.

• breakingFalse exit code 255 may have masked real container failures

  If your monitoring, alerting, or restart policies key off exit code 255, you may have been misclassifying fast-exiting containers as crashed. After upgrading, audit any runbooks or OOMKill/CrashLoopBackOff workflows that treat exit code 255 as a specific signal — the real exit codes from short-lived containers will now surface correctly.

• enhancementUpgrade straightforward for 1.33.x users — no config or dependency changes

  This is a clean drop-in replacement for v1.33.12. No dependency bumps, no config changes required. Plan a rolling node drain and replace the CRI-O binary. Prioritize nodes running batch jobs, init containers, or short-lived workloads where fast exits are common and exit code accuracy matters most.

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

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

• breakingRead the CHANGELOG before upgrading

  The release notes for v3.6.12 are essentially empty — no changes are listed inline. Before upgrading any etcd cluster, pull the full CHANGELOG-3.6.md from the repo and review all entries since your current version. The official upgrade guide explicitly warns of potential breaking changes in the 3.6 series.

• enhancementVerify container registry targets in your pipelines

  etcd maintains two registries: gcr.io is primary, quay.io is secondary. If your CI/CD or deployment manifests pin to quay.io, confirm it stays in sync with the primary. For production clusters, prefer gcr.io/etcd-development/etcd to avoid lag.

日本語 準備中etcd v3.5.31 is a patch release on the 3.5 branch. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch versions

  The etcd team explicitly calls out that breaking changes can appear in patch releases. Don't skip the upgrade guide assuming this is safe to apply blindly. Verify any API or storage format changes against your current deployment before scheduling maintenance.

• enhancementReview CHANGELOG before upgrading

  The release notes published here are sparse. Before rolling this out, pull the full CHANGELOG-3.5.md directly from the etcd repo to identify any bug fixes or behavioral changes that affect your cluster. Patch releases on 3.5 have historically included compaction fixes and lease handling improvements — worth verifying what specifically landed here.

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

• breakingCheck the official upgrade guide even for patch releases

  The release explicitly flags that breaking changes may exist. Etcd 3.4.x is a mature but still-active branch used heavily in Kubernetes clusters. Verify the upgrade guide at etcd.io before rolling this out, especially in production environments where quorum and data integrity are non-negotiable.

• enhancementReview CHANGELOG before upgrading — release notes are intentionally minimal

  This release page contains almost no detail. Before upgrading, pull up CHANGELOG-3.4.md directly in the etcd GitHub repo to understand what actually changed. Blind upgrades on etcd — your cluster's source of truth — are a bad idea regardless of how minor a patch looks.

日本語 準備中Lima v2.1.2 is a broad maintenance release fixing hostagent resource leaks, zombie processes, and gRPC connection leaks — plus template updates for Kubernetes 1.36, Ubuntu 26.04, and Fedora 44.

• breakingAlpine template split — update your instance configs

  The generic `template:alpine` has been split into `template:alpine-3.21`, `template:alpine-3.22`, and `template:alpine-3.23`. If you reference `template:alpine` in scripts, CI, or configs, those references will break. Audit and update them to a specific versioned template before upgrading.

• breaking_LIMA_QEMU_UEFI_IN_BIOS is deprecated — stop using it

  If you have the `_LIMA_QEMU_UEFI_IN_BIOS` environment variable set in any scripts or dotfiles, remove it now. The flag is deprecated in this release and will likely be removed in a future version. Check wrapper scripts and CI pipelines that invoke limactl with QEMU.

• enhancementHostagent resource leak fixes — worth upgrading if you run long-lived instances

  Four separate hostagent fixes address GuestAgentClient leaks, inotify watcher accumulation, and gRPC stream mishandling on reconnect. If you've seen memory creep or stale connections in long-running Lima instances, this release directly addresses those issues. Upgrade proactively rather than waiting.