Helm Chart Dependency Updating With Malicious Chart.yaml Content And Symlink Can Lead To Code Execution

The vulnerability stems from how Helm handles dependencies and updates Chart.lock files. An attacker can create a Chart.yaml file containing malicious content within specific fields. When Helm updates dependencies and writes the Chart.lock file, this malicious content is transferred. If the Chart.lock file is then symlinked to a file that is executed (like a bash.rc or shell script), the attacker can trigger arbitrary code execution on the system. This represents a significant risk, potentially allowing attackers to gain control of Kubernetes clusters and the underlying infrastructure. The blast radius extends to any system where the compromised Helm chart is deployed or managed.

Kubernetes administrators and developers using Helm to manage their applications are at risk. Specifically, those using older versions of Helm (≤ 3.18.4) and those who allow untrusted users to contribute to Helm charts are particularly vulnerable. Shared Kubernetes clusters and environments with limited access controls also increase the risk.

• linux / server:

find /var/lib/helm/charts -name Chart.lock -type f -exec grep -i 'malicious_content' {} + 

• linux / server:

journalctl -u helm -f | grep -i 'dependency update' 

• generic web: Inspect Helm chart repositories for suspicious Chart.yaml files. Look for unusual characters or commands within the dependencies section.

1. 2025-07-08Disclosure

   disclosure

1. 已保留2025-07-02
2. 发布日期2025-07-08
3. 修改日期2026-02-26
4. EPSS 更新日期2026-03-23

The primary mitigation is to upgrade Helm to version 3.18.4 or later. Before upgrading, assess the potential impact on existing deployments and consider a staged rollout. If an immediate upgrade is not feasible, restrict access to Helm repositories and carefully review any charts before installation. Consider implementing a Web Application Firewall (WAF) or proxy to inspect Helm chart contents for suspicious patterns. Monitor Helm logs for unusual activity, particularly during dependency updates. There are no specific Sigma or YARA rules readily available for this vulnerability, but monitoring for unexpected file modifications in the Chart.lock file location is recommended.