CVE-2026-35205: 
Helm vulnerability analysis and mitigation

CVE-2026-35205 is a signature verification bypass vulnerability in Helm, the Kubernetes package manager, where Helm fails open by installing plugins that are missing their provenance (.prov) file even when signature verification is explicitly required. It affects Helm versions 4.0.0 through 4.1.3 (inclusive) and was disclosed on April 9, 2026, with a patch released the same day in version 4.1.4. The vulnerability carries a CVSS v3.1 base score of 7.8 (High) and a CVSS v4.0 base score of 8.4 (High) (Github Advisory, Helm Security Advisory).

The root cause is classified as CWE-636 (Not Failing Securely / 'Failing Open'): when Helm's plugin installer (internal/plugin/installer/installer.go) encounters a plugin archive without a corresponding .prov provenance file, the pre-patch code emitted only a warning to stderr and continued installation rather than aborting. This meant that even with --verify enabled, an attacker-controlled plugin lacking signing data would be installed and its hooks executed. The fix changes this behavior so that a missing .prov file returns a hard error (plugin verification failed: no provenance file (.prov) found), blocking installation entirely (Helm Security Advisory, Fix Commit).

Successful exploitation allows a malicious plugin author to distribute an unsigned plugin that bypasses Helm's signature verification, causing arbitrary code execution on the system running Helm when plugin hooks are triggered during install or update. Because Helm plugins often execute with the privileges of the invoking user — who may have broad Kubernetes cluster access — this can lead to unauthorized access to sensitive workload data, cluster secret exfiltration, and potential full compromise of the Kubernetes environment. Confidentiality, integrity, and availability of the affected system are all rated High (Github Advisory, Helm Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.014–0.019% (6th percentile), indicating a low near-term exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction — a Helm user must be socially engineered or otherwise induced to install the malicious plugin — but requires no elevated privileges on the attacker's part.

1. Craft a malicious plugin: Create a Helm plugin tarball (.tgz) containing a plugin.yaml manifest and a hook script with a malicious payload (e.g., a reverse shell or credential harvester). Deliberately omit the .prov provenance/signature file from the archive.
2. Host the plugin: Publish the unsigned plugin tarball to a publicly accessible location (e.g., a GitHub release, S3 bucket, or attacker-controlled web server) or distribute it via a typosquatted plugin repository.
3. Social engineer the target: Convince a Helm user running versions 4.0.0–4.1.3 to install the plugin using helm plugin install <URL> or helm plugin update <plugin-name>, potentially by impersonating a legitimate plugin or referencing it in documentation/issues.
4. Bypass verification: On vulnerable Helm versions, the installer detects the missing .prov file, emits only a warning, and proceeds with installation — the --verify flag is effectively ignored.
5. Trigger code execution: Helm automatically executes plugin hooks (e.g., install hooks defined in plugin.yaml) upon installation. The malicious hook script runs with the privileges of the Helm user, enabling arbitrary command execution, lateral movement within the Kubernetes cluster, or exfiltration of kubeconfig credentials (Helm Security Advisory, Fix Commit).

• Logs: Helm output containing WARNING: No provenance file found for plugin followed by successful plugin installation (indicates vulnerable version behavior); absence of a verification success message when --verify was expected.
• File System: Presence of a newly installed Helm plugin directory (typically ~/.local/share/helm/plugins/<plugin-name>/) lacking a corresponding .prov file; unexpected or unfamiliar plugin names in the plugins directory.
• Process: Unusual child processes spawned by the Helm binary during plugin installation (e.g., bash, sh, curl, wget, python) that are not part of normal Helm operation; outbound network connections initiated immediately after helm plugin install.
• Network: Unexpected outbound connections from the workstation or CI/CD runner running Helm to unknown external IPs or domains shortly after plugin installation.

Upgrade all Helm installations to version 4.1.4 or later, which causes plugin installation to fail with an error when the .prov provenance file is missing and --verify is enabled (Helm v4.1.4 Release). As a temporary workaround for users unable to upgrade immediately, manually inspect plugin tarballs before installation to confirm the presence of a valid .prov file alongside the archive (Github Advisory). Additionally, restrict which users are permitted to install Helm plugins in CI/CD pipelines and production environments, and audit all currently installed plugins for missing provenance data.

The vulnerability was reported by security researcher maru1009 and disclosed via GitHub Security Advisories on April 9, 2026, with the Helm maintainer gjenkins8 publishing the fix the same day (Helm Security Advisory). The openSUSE security announce mailing list distributed a notification, and the issue was picked up by Linux compatibility news outlets (openSUSE Announce). Community reaction was generally measured given the lack of active exploitation, though the fail-open design flaw drew commentary in the context of broader package manager security concerns.