In June 2021, the Helm maintainers quietly patched a subtle but consequential flaw in how the Kubernetes package manager handles its local repository cache. Tracked as CVE-2021-32690, the issue lived in the way Helm stored and retrieved cached copies of a chart repository's index.yaml file — the manifest that tells Helm which chart versions exist and where to fetch them from. Under specific conditions, that caching behavior could be manipulated so that a client ended up resolving chart requests against the wrong repository index, a class of bug best described as cache confusion. For an ecosystem built on trusting a helm install or helm dependency update command to pull exactly the chart you asked for, that is not a cosmetic problem — it is a supply chain integrity problem.
This post breaks down what CVE-2021-32690 actually is, which Helm versions and workflows were affected, what we know about its severity and exploitability, how the disclosure and fix played out, and — importantly — what teams should do about it today, years after the patch shipped, given how long stale Helm binaries tend to survive in CI pipelines and jump boxes.
Understanding CVE-2021-32690: The Helm Chart Repository Cache Confusion Vulnerability
Helm manages chart repositories the same way most package managers manage upstream feeds: it downloads an index file describing available charts, caches that index locally, and consults the cache on subsequent operations instead of re-fetching it every time. That caching layer is what makes helm repo update, helm search repo, and helm dependency update fast.
The problem addressed by CVE-2021-32690 was that Helm's local index cache did not bind cached repository data tightly enough to the repository it actually came from. Because of how cache entries were keyed and referenced, it was possible for the wrong cached index — associated with a different repository than the one currently configured — to be consulted during dependency resolution. In practice, this meant a user or automated pipeline could believe it was pulling a chart (or a chart dependency) from one trusted chart repository, while Helm was actually resolving that request against index data belonging to a different, potentially attacker-influenced repository entry in the local cache.
That distinction matters enormously in a CI/CD context. Helm charts routinely declare dependencies on other charts hosted in separate repositories, and helm dependency update walks those repository references automatically, without a human reviewing each resolution. If the cache confusion could be steered by an attacker who controls repository naming or ordering in a shared environment (for example, a CI runner that adds and removes repos across pipeline runs, or a multi-tenant build system), the practical outcome is the installation of an unintended chart — potentially one that was never meant to be trusted for that project. That is a textbook software supply chain risk: the tooling, not the operator, silently substitutes what gets deployed.
Affected Versions and Components
CVE-2021-32690 affects the Helm 3.x line prior to Helm 3.6.1, which is the release that contains the fix. Helm 2 was already end-of-life by the time this issue was disclosed and is out of scope for the official advisory. The affected component is Helm's client-side repository index caching logic — the code path exercised by commands such as helm repo add, helm repo update, helm dependency update, and helm dependency build, all of which read from or write to the local chart repository cache.
It's worth being precise about what this is not: it is not a flaw in the Kubernetes API server, not a container runtime issue, and not a vulnerability in any specific chart. It is a client-tooling defect in the Helm CLI/library itself, which means every consumer of the affected Helm versions — whether invoked interactively by a platform engineer or embedded inside a GitOps controller or CI job — inherited the exposure until they upgraded.
CVSS, EPSS, and KEV Context
Public vulnerability databases classify CVE-2021-32690 as a low-severity issue relative to the broader Helm advisory batch released alongside it in the 3.6.1 update. The reduced severity reflects the fact that exploitation depends on fairly specific preconditions — attacker influence over which repositories get added to a shared cache and in what order — rather than a remotely triggerable, unauthenticated path. There is no indication that CVE-2021-32690 has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and it has not been associated with any significant EPSS (Exploit Prediction Scoring System) activity suggesting active or widespread exploitation.
That said, "low severity" in a CVSS score should not be read as "low priority" for a software supply chain team. Cache and dependency-resolution confusion bugs are exactly the class of issue that tends to be chained with other weaknesses — a compromised or typosquatted chart repository, a misconfigured shared build agent, or a poorly isolated multi-tenant CI environment — to achieve a much more damaging outcome than the standalone score implies. Helm is the de facto Kubernetes package manager for a large share of production clusters, so any defect touching how it decides which chart bytes actually get deployed deserves attention proportional to that blast radius, not just its raw CVSS number.
Disclosure Timeline
- Discovery and private reporting: The issue was identified and reported through Helm's responsible disclosure process, alongside several other repository- and cache-related findings surfaced around the same time.
- Coordinated fix: The Helm maintainers addressed CVE-2021-32690 as part of the Helm 3.6.1 release in June 2021, which bundled fixes for a cluster of related caching and index-handling issues disclosed together.
- Public advisory: A corresponding GitHub Security Advisory and CVE record were published to document the flaw, its root cause, and the fixed version, giving downstream consumers a clear upgrade target.
- Ongoing exposure: Because Helm binaries are frequently vendored into base images, CI runner images, and long-lived build tooling, organizations that pinned Helm versions before mid-2021 may still be running vulnerable clients years after the official fix — a common pattern with client-side tooling CVEs that never accumulate the urgency of a server-side remote code execution bug.
Remediation Steps
Remediating CVE-2021-32690 is straightforward once it's on your radar, but the discovery step is often the harder part:
- Upgrade Helm to 3.6.1 or later. This is the definitive fix. Any Helm 3.x release from 3.6.1 onward contains the corrected repository cache handling.
- Inventory every place Helm runs, not just developer laptops. CI/CD pipelines, GitOps operators (Argo CD, Flux), base container images, and internal tooling often embed a specific Helm binary version that can lag well behind what engineers run locally.
- Clear stale local caches after upgrading. Since the vulnerability concerns cached index state, wiping
~/.cache/helm(or the equivalent cache directory) after upgrading ensures no residual, potentially confused cache entries persist across the version bump. - Reduce shared-cache blast radius in multi-tenant build environments. Avoid running Helm dependency resolution for multiple unrelated repositories/tenants against a shared, long-lived cache directory or long-lived CI runner without isolation.
- Pin and verify chart repository sources explicitly in automation, and prefer chart provenance/signature verification where available, so that even a resolution mistake is caught before an unexpected chart reaches a cluster.
- Track Helm's security advisories going forward — this was one of a small cluster of Helm caching and dependency-handling CVEs disclosed in the same release window, and staying current on the 3.x line closes all of them at once.
How Safeguard Helps
Vulnerabilities like CVE-2021-32690 are a reminder that software supply chain risk doesn't only live in application dependencies — it lives in the package managers, CLIs, and CI tooling that decide what actually gets pulled and deployed. A stale Helm binary sitting quietly in a base image or a shared runner is invisible to most security tooling that only scans application manifests and container layers, yet it directly controls what Kubernetes workloads end up running.
Safeguard is built to close exactly that visibility gap. Our platform continuously inventories the software supply chain across your build and deployment pipelines — including tooling like Helm, its chart repositories, and the dependency chains that flow through Chart.yaml files — and maps known CVEs like CVE-2021-32690 against the actual versions in use, not just what's declared in a manifest. That means Safeguard can flag an outdated Helm client baked into a CI image or a GitOps controller long before it becomes an incident, and correlate it with real exploitability context (CVSS, EPSS, and KEV status) so your team can prioritize the fixes that matter instead of chasing every low-severity advisory equally.
Beyond detection, Safeguard helps enforce the guardrails this class of vulnerability calls for: verifying chart provenance, monitoring for unexpected chart repository additions in CI environments, and ensuring remediation guidance — like upgrading to a patched Helm release — gets tracked to closure rather than logged and forgotten. For teams running Kubernetes at scale, that continuous, supply-chain-aware view is what turns a years-old, easy-to-miss CVE into a fast, low-drama fix rather than a lingering blind spot.