A critical vulnerability in the Kubernetes package manager Helm allows malicious actors to take over developer workstations and CI/CD pipelines. Tracked as CVE-2025-53547, the flaw exploits how Helm writes a lock file during routine dependency updates. If an attacker can trick the system into using a symlinked Chart.lock file, they can overwrite executable startup scripts and gain code execution. Helm v3.18.4 fixes the issue, and an immediate upgrade is essential for anyone who runs helm dependency update on untrusted charts.

What Went Wrong

When you run helm dependency update, Helm reads the Chart.yaml metadata and generates a Chart.lock file that pins dependency versions. Prior to v3.18.4, Helm would follow a symbolic link if Chart.lock pointed to a file outside the chart directory. An attacker who supplies a malicious Chart.yaml and crafts Chart.lock as a symlink to, say, ~/.bashrc or a CI startup script can inject arbitrary content into that target. The next time that script executes—whether during a shell login or an automated build—the injected code runs with the victim’s privileges.

The core issue is a symlink-following bug (CWE‑94) in the lock file write path. Helm did warn about the symlink but still wrote through it. The result: a supply‑chain‑adjacent attack where a poisoned chart can silently compromise a machine that merely updates dependencies. The CVSS score hovers around 8 or higher, reflecting its high severity.

Who Needs to Worry

If you run Helm on Windows via WSL, Docker, or a native binary, the same vulnerability applies—the attack works on any operating system where Helm runs and symlinks are supported. The risk divides into three practical scenarios:

  • CI/CD pipelines. Automated runners frequently execute helm dependency update against charts from pull requests or public repositories. An attacker who submits a malicious PR can hijack the runner, steal secrets, or tamper with build artifacts.
  • Developer workstations. Cloning a repository that contains a malicious Chart.lock symlink and running a dependency update can overwrite your shell startup files, giving the attacker persistent local access.
  • SDK users. Applications that embed Helm’s Go package (e.g., internal tooling, GitOps controllers) are also vulnerable if they invoke downloader.Manager for dependency updates without sandboxing.

Home lab users and casual experimenters are less exposed, but any untrusted chart source—whether a public repo or an unfamiliar OCI registry—carries risk if you run dependency updates.

How We Got Here

Helm has always written a Chart.lock file during dependency operations, and by default it respected filesystem symlinks. The behavior was not malicious but simply permissive. As security scrutiny of supply‑chain tools intensified, researchers identified that an attacker could chain two seemingly harmless behaviors—metadata propagation from Chart.yaml and symlink following—into a code‑execution primitive.

This is not the first time Helm had to tighten file handling. In v3.17.3, maintainers introduced decompression limits to prevent denial‑of‑service via huge archives. That change broke some legitimate charts, and some operators delayed upgrading. The same operational friction may appear here, but the security stakes are far higher.

The vulnerability was reported through responsible disclosure, and Helm v3.18.4 was released with a straightforward fix: Chart.lock writes now fail safely if the file is a symlink or would escape the chart directory.

Immediate Steps to Protect Your Systems

1. Upgrade Helm to v3.18.4

This is the definitive fix. Check your current version:

helm version

If it reports anything older than v3.18.4, you are vulnerable. Upgrade on all hosts—developer laptops, CI runners, and any container images that bundle the Helm binary.

  • Windows (native): Download the latest binary from Helm’s releases page or use a package manager like choco upgrade kubernetes-helm.
  • WSL/Docker: Update the helm binary inside your Linux environment using your package manager or by downloading the binary directly.
  • CI/CD images: Rebuild Docker images that include Helm with the new version, and push updated images to your registry.

2. Eradicate Symlinked Chart.lock Files

Scan your repositories and artifact stores for any Chart.lock files that are symlinks. On Linux/WSL, run:

find . -name "Chart.lock" -type l

If you find them, remove or replace them with actual files. Add a pre‑commit hook or CI check to reject new symlinked lock files. Many chart repositories, such as those hosted in ChartMuseum or Harbor, can be configured to block such artifacts.

3. Sandbox Dependency Updates

Until you have upgraded everywhere, or if you must process untrusted charts, force helm dependency update to run in isolated environments:

  • Use ephemeral Docker containers with a restricted filesystem and no access to user home directories or system startup paths.
  • In CI, execute Helm commands inside a container that mounts only the chart directory itself.
  • For GitHub Actions or similar, run the update in a job that uses a disposable runner with credentials scoped to the bare minimum.

4. Harden CI/CD Pipelines

  • Rotate any secrets that may have been exposed to runners during the vulnerable window.
  • Rebuild all artifacts produced by potentially compromised runners.
  • Enable debug logging temporarily to audit helm invocations and correlate them with inputs from pull requests.

5. Protect SDK Consumers

If you embed the Helm SDK, update your Go dependency to helm.sh/helm/v3 at v3.18.4 or newer. Review code that calls Manager.Update() and wrap it in OS‑level protections (e.g., drop privileges, use a chroot‑like sandbox). Treat any process that accepts untrusted chart data as a critical attack surface.

Outlook

The patch is surgically simple, but the operational work of finding every Helm binary across an organization is the real challenge. Many DevOps teams will discover forgotten CI configurations or legacy images still running vulnerable versions weeks later. Beyond this CVE, the incident reinforces a growing lesson: developer tools that process untrusted configuration files must treat symlinks and other filesystem abstractions as potentially hostile. Helm’s maintainers are likely to continue locking down such vectors, and future releases may introduce additional security-related breaking changes. For now, updating to v3.18.4 and implementing the controls above puts you on the right side of this vulnerability.