Helm 3.22.1 ships with under four months of security support left: what Helm 4 asks of you
Victoria Shinder3 min readThe Helm project shipped two patch releases this week: Helm 4.3.1 on 15 October and Helm 3.22.1 the same day. The notes for both end with the same line: 4.3.2 and 3.22.2 are scheduled for 11 November 2026, 4.4.0 for 13 January 2027, and "there will be no further Helm 3 minor releases". For teams still on the 3.x line, that sentence is the news; the patches themselves are small.
What the two patches contain. Helm 3.22.1 bumps dependencies "to remove Go package vulnerabilities" and updates the k8s.io Go packages; its changelog moves golang.org/x/net to v0.60.0 for five Go advisories (GO-2026-6603, -6610, -6611, -6612 and -6617) and the k8s.io group to v0.37.1. Helm 4.3.1 lists two notable changes: waiting for CRD establishment under the hook-only strategy (#32672) and a golangci-lint update, plus a golang.org/x/net bump to v0.61.0 and other dependency updates.
The dates that matter. According to the project's end-of-life post, the maintainers added one extra, limited feature release on 9 September 2026 — restricted to Kubernetes client library updates for new Kubernetes versions, with no other features backported — and extended security support by three months to 10 February 2027. Bug fixes ran up to that final feature release. After February 2027, the post says, Helm 3 will receive no updates at all, including Kubernetes client libraries and security patches. At the time of 3.22.1, that leaves under four months.
What the project says carries over. The maintainers write that charts deployable with Helm 3 should be deployable with Helm 4, and that releases managed by Helm 3 should generally be upgradable by Helm 4, so the binary can be swapped without rewriting charts or redeploying releases. New releases use server-side apply by default, while upgrades of existing Helm 3 releases automatically latch to client-side apply.
What does not carry over unchanged. The same post lists the breaking changes, and they are where a migration plan has to look: helm install --post-renderer now takes a plugin name instead of an executable path, so post-renderer workflows must be rewritten as plugins; helm registry login accepts domain names only, not full URLs; and --atomic became --rollback-on-failure and --force became --force-replace — the old flags still work but print deprecation warnings. Anything that parses Helm's output or wraps the CLI in scripts is where those warnings will surface first.
Why the line is being drawn. The post says Helm 3 accumulated technical debt and architectural limits that prevented new features without breaking the SDK's public APIs; Helm 4, released in November 2025, makes those breaks once and declares the SDK API stable. It also lists what 3.x users have not had: an optional WebAssembly-based plugin runtime, kstatus-based resource monitoring, values split across several YAML files and custom template functions through plugins.
The practical reading. For an operator, the patch notes and the end-of-life post together give a short checklist drawn from the project's own text: inventory post-renderers and registry logins, replace the two renamed flags in scripts before the warnings become noise, and plan the switch before 10 February 2027 — after which a Helm 3 binary is, in the maintainers' words, no longer receiving any updates.
Source: Helm, "Helm 3 End of Life" — https://helm.sh/blog/helm-v3-end-of-life/ ; releases: https://github.com/helm/helm/releases/tag/v3.22.1 and https://github.com/helm/helm/releases/tag/v4.3.1