Vulnerability Directory | CVE-2026-35204

Overview

Helm is the Cloud Native Computing Foundation graduated package manager for Kubernetes. It packages Kubernetes manifests into charts and supports a plugin model that lets users extend the helm command line with first- and third-party tools. Plugin metadata lives in a plugin.yaml file at the root of the plugin archive, including a version field that Helm uses when laying the plugin out under the Helm plugin directory.

A path traversal vulnerability (CVE-2026-35204) has been identified in the Helm plugin install and update path. The version field in plugin.yaml is interpolated into the plugin's on-disk path without validation, so a crafted plugin can use parent-directory references in the version string to write arbitrary files outside the Helm plugin directory when installed or updated, including paths reachable by the user running helm.

Per OWASP: a Path Traversal attack (also known as directory traversal) lets an attacker read or write files outside the intended directory tree by manipulating file path inputs that are not properly sanitized.

This issue affects Helm versions 4.0.0 through 4.1.3, and reaches Ingress NGINX Controller deployments through the helm.sh/helm/v4 module that ships in the controller's build graph. HeroDevs has resolved it in NES for Ingress NGINX 1.15.2, the first commercial extended-support release after the Kubernetes project's March 2026 retirement of Ingress NGINX.

‍

Why this matters for Ingress NGINX deployments

None of the CVEs HeroDevs resolved in NES for Ingress NGINX 1.15.2 live in ingress-nginx code itself. They live in the dependencies the controller ships with: the Go toolchain, Helm, and a small set of Go modules. As described in the Kubernetes project's November 2025 retirement announcement, best-effort upstream maintenance ended in March 2026, and there will be no further releases, bug fixes, or security patches for any vulnerability discovered in the project or its dependencies.

That last clause is the operational problem. The Go toolchain ships security patches every six to eight weeks. Helm has shipped multiple critical CVEs in the past 12 months and is on an active patch cadence (CVE-2026-35204 and CVE-2026-35205 landed in the same Helm 4.1.4 release). Smaller transitive dependencies sit deep in the dependency tree where most teams never look until a scanner flags them. Ingress NGINX's CVE clock keeps ticking through these dependencies even though no one upstream is rebasing the build to consume the fixes.

NES for Ingress NGINX 1.15.2 is built on upstream ingress-nginx v1.15.1 with the dependency stack rebuilt to consume the patched components. The container image and Helm chart are drop-in replacements for the upstream v1.15.1 build and require no configuration change.

‍

Details

Module Info

Product: Helm (Kubernetes package manager); transitive dependency of Ingress NGINX Controller
Affected components: Helm plugin install and update path; plugin.yaml version field handling
Affected versions: Helm 4.0.0 through 4.1.3; Ingress NGINX builds that include those Helm versions in their build graph
Upstream GitHub repository: <https://github.com/helm/helm>
Published artifacts (NES):

Container image: registry.nes.herodevs.com/neverendingsupport/ingress-nginx-controller:v1.15.1-nes-1.15.2
Helm chart: HeroDevs/ingress-nginx --version 0.0.2 (see helm-charts documentation)
Release notes: docs.herodevs.com/ingress-nginx/release-notes

Distribution channels: registry.nes.herodevs.com, HeroDevs Helm chart repository
Fixed in:

Helm 4.1.4 (upstream)
NES for Ingress NGINX 1.15.2 (April 20, 2026), which bumps helm.sh/helm/v4 from 4.1.3 to 4.1.4

Vulnerability Info

This High-severity vulnerability is found in the plugin install and update path of Helm 4 and reaches every binary that links the helm.sh/helm/v4 module, including Ingress NGINX Controller builds prior to NES 1.15.2.

The Helm plugin layout is computed by joining the configured plugin directory with the plugin name and the version field declared in plugin.yaml. The expected flow treats version as a SemVer-like identifier, but the install path does not validate the field for path-separator characters or parent-directory references before using it as a directory component. A crafted plugin that sets version to a value containing ../ traversal sequences (or absolute paths on systems where the join is permissive) causes Helm to lay plugin contents outside the plugin directory.

The flaw is that plugin.yaml is treated as a trusted manifest at install time even though its contents are entirely under the plugin author's control. When the install path materializes the plugin, the version-derived directory component is concatenated with the plugin's bundled files, allowing an attacker to write arbitrary files to any path reachable by the user running helm plugin install or helm plugin update. Combined with CVE-2026-35205 (the missing-provenance fail-open in the same release window), an unsigned malicious plugin can both bypass signature verification and write arbitrary files to disk.

Threat model for Ingress NGINX clusters: any operator workflow, CI runner, or admin workstation that installs Helm plugins as part of the Ingress NGINX deployment lifecycle inherits this primitive. Plugin install hooks run as the invoking user; the path traversal lets a malicious plugin overwrite shell rc files, SSH authorized_keys, container entrypoints, or kubeconfig files reachable from the helm process. On a CI runner that handles Kubernetes credentials, the practical outcome is cluster compromise.

When successfully exploited, this vulnerability can lead to:

Arbitrary file write on hosts that run helm plugin install or helm plugin update
Code execution as the invoking user via overwrite of shell init files, cron entries, or systemd unit files reachable from the user's $PATH
Theft or rotation of kubeconfigs, cloud credentials, and CI secrets reachable by the helm process, leading to lateral movement into clusters managed by the compromised account

‍

Proof Of Concept

A reference reproduction is documented in upstream advisory GHSA-vmx8-mqv2-9gmg and the Helm fix at <https://github.com/helm/helm/commit/36c8539e99bc42d7aef9b87d136254662d04f027>.

‍

Mitigation

OSS Users

Users of upstream Helm and Ingress NGINX should apply one of the following mitigations:

Upgrade Helm to 4.1.4 or later on every workstation, CI runner, and bastion that runs helm plugin install or helm plugin update.
Until upgrade is possible, only install plugins from sources you have separately attested (out-of-band hash check against the upstream release, signed Git tag of plugin source, internal mirror with strict review). Do not rely on --verify alone (see CVE-2026-35205).
Audit currently installed plugins (helm plugin list) and the surrounding directory tree for files written outside the Helm plugin directory during the affected window.
For Ingress NGINX specifically, note that no upstream release of ingress-nginx will rebase against Helm 4.1.4 because the project retired in March 2026. Sign up for post-EOL security support; HeroDevs customers get immediate access to a patched Ingress NGINX build.

NES Customers

HeroDevs Never Ending Support for Ingress NGINX has resolved CVE-2026-35204 in NES for Ingress NGINX 1.15.2 by upgrading the bundled helm.sh/helm/v4 module from 4.1.3 to 4.1.4. The release ships as a drop-in replacement for upstream ingress-nginx v1.15.1:

Pull the patched container image: registry.nes.herodevs.com/neverendingsupport/ingress-nginx-controller:v1.15.1-nes-1.15.2
Or upgrade via the public Helm chart: HeroDevs/ingress-nginx --version 0.0.2 (helm-charts documentation)
VEX (Vulnerability Exploitability eXchange) statements ship with the release so Trivy, Grype, Snyk, and other scanners that consume OpenVEX or CycloneDX VEX surface the patched status instead of leaving CVE-2026-35204 as an open finding.

‍

Compliance impact

Ingress NGINX sits at the edge of the cluster, which means every CVE flagged against the controller binary tends to land in front of compliance reviewers, audit reports, and customer questionnaires. CVE-2026-35204 is exactly the kind of dependency CVE that surfaces in scans, has a patch upstream in Helm, and still fails an audit for organizations running upstream ingress-nginx because nothing has been republished against the patched dependency.

Several frameworks make this an acute issue:

The EU Cyber Resilience Act's Article 14 reporting obligations begin September 11, 2026; "the upstream project no longer ships fixes" is not a valid answer.
DORA's ICT third-party risk requirements have been in force since January 2025.
PCI DSS 4.0 expects continuous evidence that components receive security patches.
FedRAMP authorizations carry continuous monitoring obligations.

The NES release ships a documented patch trail for each CVE plus VEX statements that scanners consume programmatically, closing the gap between what the scanner reports and what compliance reviewers can verify.

‍

Taking Action

If your operators or pipelines run helm plugin install or rely on Helm 4.x for any part of the Ingress NGINX deployment lifecycle, treat unaudited plugin installs as untrusted until you have rolled out Helm 4.1.4 and re-audited recent plugin activity. For Ingress NGINX deployments specifically, the upstream project will not ship a release that picks up Helm 4.1.4: the controller retired in March 2026 and is in dependency-CVE drift. NES for Ingress NGINX 1.15.2 is the patched build for clusters that cannot complete a Gateway API migration before regulatory deadlines. Pull the 1.15.2 image and Helm chart per docs.herodevs.com/ingress-nginx/release-notes.

‍