By ByteBot
Helm shipped two high-severity CVEs this week, and one of them does something particularly insidious: it allows an unsigned plugin to pass signature verification without a valid provenance file. No error, no warning — just silent success, followed by arbitrary code running with your CI credentials. If your pipeline runs helm plugin install on any version from 4.0.0 to 4.1.3, you are exposed. Version 4.1.4 closes it. Upgrade now.
CVE-2026-35205: The Verification That Doesn’t Verify
The bug lives inside Helm’s plugin install logic. When signature verification is enabled, Helm checks for the .prov (provenance) file — the signed manifest that proves a plugin hasn’t been tampered with. The flaw: if the .prov file is entirely absent, Helm treats its absence as a pass rather than a failure. An attacker doesn’t need to forge a signature. They just ship a plugin with no provenance file at all.
What runs next is not benign. Plugin install hooks execute with the privileges of whoever invoked helm. On a developer workstation, that’s your user account. In CI, it’s the service account whose environment variables include KUBECONFIG, AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS, and whatever else your pipeline needs to deploy. The official advisory (GHSA-q5jf-9vfq-h4h7) is explicit: “the plugin’s install hooks run with the operator’s privileges.” CVSS v3.1 scores this at 7.8; CVSS 4.0 scores it 8.4. A fail-open default in a security check is not a medium-severity inconvenience — it is a design mistake that hands an attacker your keys.
CVE-2026-35204: Path Traversal on Top of It
The second vulnerability carries the higher CVSS score: 8.6. Helm reads the version field from a plugin’s plugin.yaml and uses it to construct the on-disk path for plugin installation. That field is not validated for path traversal sequences. Set version: ../../etc/cron.d/evil and Helm writes plugin contents outside its own directory — to whatever location the running user can write.
Used alone, CVE-2026-35204 requires a crafted plugin to reach the target. Combined with CVE-2026-35205, a single helm plugin install call delivers an unsigned plugin that bypasses verification and writes arbitrary files to the host. One command, two exploits.
Why CI Pipelines Are the Real Target
A local Helm exploit is bad. A CI exploit is a cluster breach. Helm is used by over 80% of Kubernetes adopters according to the CNCF annual survey — roughly 4.5 million developers. Of those, a large majority use Helm inside automated pipelines. The attack surface isn’t your laptop. It’s every GitHub Actions runner, every Jenkins agent, every Argo CD application controller that calls helm plugin install as part of cluster setup or onboarding.
The attack vector is practical: a malicious plugin recommendation in a forum post, a compromised plugin repository, or a pull request that adds a new plugin to a pipeline step. The attacker doesn’t need code review approval. They need the pipeline to run helm plugin install once.
Check Your Version, Then Upgrade
Affected versions: Helm 4.0.0 through 4.1.3. Check first:
helm version --template='{{ .Version }}{{ "\n" }}'To upgrade:
# macOS
brew upgrade helm
# Linux / macOS via install script
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bashAfter upgrading, re-run the version check. You need v4.1.4 or later. The official Helm install guide covers additional package managers including Chocolatey, apt, and snap. If you cannot upgrade immediately: disable helm plugin install steps in CI pipelines, and manually verify that plugin archives include a .prov file before running them locally.
What About Helm 3?
CVE-2026-35205 and CVE-2026-35204 are Helm 4.0.0–4.1.3 issues only. Helm 3.x users are not exposed to these two — but are exposed to CVE-2026-35206 (CVSS 4.4), a helm pull --untar flaw that writes chart contents to the wrong directory. The fix is Helm 3.20.2. Also worth noting: as covered here yesterday, Helm 3.22.0 is the final 3.x release. Security patches for 3.x will stop. The EOL clock and this CVE batch together make the case for moving to 4.x sooner rather than in February.
The Broader Lesson
Fail-open defaults in security checks are not edge cases — they are one of the most common classes of authentication and verification vulnerability. Helm’s provenance system was designed to let teams trust plugins. CVE-2026-35205 shows that “requires verification” and “enforces verification” are two different things. The same dynamic appears in npm package audits, pip dependency checks, and container image signing workflows. When the absence of a signature file is treated as a pass, attackers exploit the gap. Helm 4.1.4 closes this one. It is worth auditing what else in your stack makes the same assumption.
