リリース

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.

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.

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.

Security-only patch fixing a path traversal vulnerability in chart extraction. Upgrade immediately if you pull charts from untrusted sources.

• securityPatch a chart extraction path traversal — upgrade now

  A crafted Chart.yaml using dot-segments (e.g., '..') in the chart name could cause Helm to write files outside the intended extraction directory. This is a classic directory traversal attack vector. If your pipelines pull charts from public repos, third-party registries, or any source you don't fully control, treat this as critical and upgrade to v3.20.2 today. Teams operating fully air-gapped with only internally authored charts have lower immediate risk, but should still upgrade on the next maintenance window.

Helm v4.1.4 is a security-only patch fixing three vulnerabilities: chart extraction path traversal, plugin signature bypass, and plugin version path traversal enabling arbitrary file writes.

• securityUpgrade immediately — all three CVEs are exploitable via untrusted input

  Two of these bugs (chart extraction collapse and plugin version path traversal) allow writing files to arbitrary locations on the filesystem. The third lets anyone install an unsigned plugin if they control the distribution channel. If your CI/CD pipeline pulls charts or plugins from external or semi-trusted sources, you are exposed on any Helm version before this patch. Upgrade to v4.1.4 (or v3.20.3 when released April 8) now. Don't wait for a maintenance window.

• securityAudit your plugin sources before upgrading — unsigned plugins may have slipped through

  The provenance bypass (GHSA-q5jf-9vfq-h4h7) means any Helm installation that had plugin verification enabled could still have installed unsigned plugins if the .prov file was simply absent. Before upgrading, audit installed plugins with 'helm plugin list' and verify their origins manually. After upgrading, reinstall any plugins from official sources to ensure provenance is properly checked.

• enhancementPin Helm in CI to this exact version now

  If you use a floating version reference like 'latest' or a minor-pinned tag in your CI pipeline, update it to v4.1.4 explicitly. The Helm team also pinned the CodeQL action to a commit SHA in this release — a good reminder to apply the same discipline to your own toolchain dependencies.

Helm v3.20.1 fixes two critical bugs affecting chart value handling and OCI registry operations that could cause deployment failures.

• enhancementUpgrade immediately for value handling fixes

  This patch resolves two bugs that could break chart deployments. The nil value preservation fix prevents unexpected behavior when overriding chart defaults, while the OCI tag+digest fix enables proper chart pulling from registries using both identifiers. Test your existing charts after upgrading to ensure value overrides work as expected.

• enhancementVerify OCI chart references work properly

  If you use OCI registries with tag+digest references (like `registry/chart:v1.0@sha256:abc123`), this release fixes previous 'invalid byte' errors. Update your CI/CD pipelines to use this version before relying on tag+digest combinations for chart immutability.

Helm v4.1.3 patches multiple critical bugs affecting OCI registries, dry-run operations, and value handling that were causing deployments to fail or behave unpredictably in production environments.

• breakingUpdate OCI registry workflows immediately

  If you use OCI registries that store both container images and Helm charts under the same tag, upgrade now. The previous bug caused complete pull failures. Test your chart pulls after upgrading to ensure compatibility with your registry setup.

• enhancementReview autoscaling upgrade timeouts

  Upgrades now properly wait for cluster autoscalers and rolling updates instead of failing prematurely. Review your deployment pipelines and consider reducing any artificial delays you added to work around this issue. Monitor initial upgrades closely to verify improved behavior.

• enhancementValidate dry-run operations with generateName

  Server-side dry-run now correctly handles generateName fields. If you've been avoiding dry-run validation for resources using generateName, re-enable it in your CI/CD pipelines. This improves pre-deployment validation coverage.