Detecting vulnerabilities in public Helm charts

Learn how to identify and prevent RBAC flaws, secret leaks, and malicious templates in public Helm charts using Trivy, GitHub Search, and OPA.

What is Helm?

Helm is the de facto Kubernetes package manager, originally created by DeisLabs and now a graduated CNCF project. Think of it like apt or yum, but for Kubernetes apps. It simplifies the deployment process by using Helm charts, pre-packaged collections of YAML configurations that describe a Kubernetes application.

# Add a public Helm chart repository
helm repo add <alias> https://<orgname>.github.io/helm-charts

# Install a Helm chart
helm install my-<chart-name> <alias>/<chart-name>

# Uninstall a Helm chart
helm uninstall my-<chart-name>

Why Helm security matters

Helm provides a powerful abstraction layer, but security is not enforced by default. With over 9000+ charts available on Artifact Hub, the responsibility of securing deployments largely falls on users. In May 2025, Microsoft’s Defender for Cloud team warned about the widespread risks associated with Helm’s default settings.

To determine how widespread this issue is, researchers at Microsoft conducted a thorough investigation with GitHub Code Search to find repositories for YAML files containing strings that may indicate a misconfigured workload, such as type: LoadBalancer. This is the search query used to find projects like Meshery that provide a default configuration that had widespread usage, and is exposed to the public internet:

("kind: Ingress" OR "type: LoadBalancer" OR "type: NodePort") AND "meshery" AND "helm" AND language:YAML

Microsoft’s research team evaluated the most popular Helm Charts by deploying them in controlled test environments. Their objective was to assess the security posture of these charts as they ship out-of-the-box, specifically, to determine which applications are publicly exposed by default and whether they include any form of authentication or access control. Let’s now explore practical takeaways from this research that you can apply within your own organization.

Read more: How curiosity, Kubernetes, and community shaped my open source journey

1. Insecure configurations

Helm templates often define over-permissive RBAC rules or elevated security contexts that can open up serious security gaps.

Dangerous RBAC: Cluster-wide access

# templates/rbac.yaml
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

This gives admin-level permissions across the cluster. If a pod using this service account is compromised, the attacker gains full access.

GitHub search for insecure RBAC

The below Github Search query should show you if your popular open source project is providing Helm charts with wildcards set in the RBAC configuration:

path:/templates/ path:**/rbac.yaml ("apiGroups: [\"*\"]" OR "resources: [\"*\"]" OR "verbs: [\"*\"]") AND "helm" AND language:YAML

Privileged securityContext

securityContext:
  privileged: true
  allowPrivilegeEscalation: true

Similarly, you can use Github Search queries as a way to see whether these elevated settings are configured in the securityContext of your workloads:

"securityContext" AND ("privileged: true" OR "allowPrivilegeEscalation: true")  AND "helm" AND language:YAML

The last time I checked there were more than 23,000 results for this generic, default configuration. This is pretty concerning when you think that most workloads don’t actually need root-level permissions.

Read more: Introduction to Falco and how to set up rules

2. Default values exposing secrets

Hardcoding secrets like passwords or API keys in values.yaml is a common anti-pattern.
We’re looking out to avoid this kind of configuration in our project:

database:
  username: admin
  password: mysecretpassword123

A secure alternative is to use Kubernetes Secrets.

database:
  existingSecret: db-credentials-secret
  passwordKey: password

However, it’s worth noting that Base64 encoded tokens are not a replacement for encryption. These can easily be decoded with tools such as: www.base64decode.org.

# kubernetes-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials-secret
type: Opaque
data:
  password: bXlzZWNyZXRwYXNzd29yZDEyMw==  # base64-encoded

Just to give you an idea of how frequently sensitive credentials are exposed in Helm Charts, create a modified version of the below Github Search query on public Github projects:

path:/charts/ AND "password" AND "base64" AND "helm" AND language:YAML

Read more: Why Kubernetes is essential for AI and open source projects in 2025

3. Dependency vulnerabilities

So far we are only pointing to the insecure configurations and credentials that are exposed within Helm charts. However, Helm charts often define external dependencies, such as vulnerable Docker container images, or even other Helm charts. These dependencies are frequently outdated or unmaintained. 

In these scenarios, it’s a good practice to regularly run vulnerability scanners on your charts. In this blog, I recommend open source Trivy as the tool to scan these charts for vulnerabilities and known misconfigurations that were previously addressed.

helm template ./mychart | trivy k8s --security-checks config -
2025-05-20T10:00:00.000Z	INFO	Detected config files: 1
2025-05-20T10:00:00.000Z	INFO	Scanning Helm chart...
my-helm-chart/templates/deployment.yaml (kubernetes)
  [SECURITY][CRITICAL] Hardcoded Secret in Environment Variable
  Message: A hardcoded password was found in the container environment variables.
  Object: Deployment/my-app
  Field: spec.template.spec.containers[0].env[1].value
  Value: mysecretpassword123
  Remediation: Use a Kubernetes Secret to manage sensitive environment variables instead of hardcoding them.
my-helm-chart/values.yaml
  [SECURITY][HIGH] Hardcoded Secret in values.yaml
  Message: A potential secret was detected in values.yaml
  Field: database.password
  Value: mysecretpassword123
  Recommendation: Move this value to a Kubernetes Secret and reference it via `existingSecret`.

You can also manually check for insecure configurations after you’ve deployed the containerised application via Helm. This workload can work during the test phase:

But manual reviews aren’t enough. At Cloudsmith, we integrate Trivy at the pipeline-stage to automatically scan Helm charts before they get into production. We also integrate open source Open Policy Agent (OPA) to make decisions on what packages can be used based on specified vulnerability thresholds taken from Trivy.

Just to give readers an idea of how insecure default Helm charts can be, I rendered a brand new Helm template. It’s only the skeleton of a real containerised web application. You get two services, a services account, and a few other generic configurations such as RBAC and NetworkPolicy that you’re expected to make changes to:

I scanned the chart manually in Trivy and it showed three HIGH vulnerabilities as well as other lesser priority vulnerabilities that I chose to filter out. These HIGH categorized vulnerabilities are always around permissions. To ensure everything works smoothly out-of-the-box (“as-is”), the workloads are given more permissions than are actually needed. It’s up to the end user to make these changes manually.

4. Risk of altered or malicious charts

Using Helm charts from untrusted or poorly maintained sources can expose your Kubernetes environment to serious risks. A compromised or malicious chart might include backdoors, data exfiltration logic, or misconfigurations that weaken your cluster’s security. The impact can range from a single application being compromised to broader lateral movement across the environment.

To reduce this risk, always validate the provenance of a chart before deploying it, particularly when sourcing from public repositories like Artifact Hub.

Key factors to evaluate include:

1. Chart maintenance: Is the chart actively maintained and regularly updated, or has it gone stale?
2. Community trust signals: Does the chart have a healthy number of stars, downloads, or community endorsements?
3. Publisher authenticity: Is the chart published by a verified maintainer or a known trusted entity?

While these checks aren’t foolproof, they provide a critical first layer of defense against supply chain attacks involving vulnerable or intentionally malicious charts. Let’s check out some of those malicious chart scenarios.

Chart exploits – “ChartSploit”

Helm chart exploits are very real, but we use ChartSploit as a way to show a hypothetical attack workflow:

• Attacker finds a Helm chart with vulnerable RBAC or default secret.
• They inject a malicious payload into values.yaml.
• The chart is deployed via CI/CD, giving the attacker access.

Example vulnerable template:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-config
data:
  config.json: |
    {
      "external_url": "{{ .Values.externalUrl }}"
    }

If externalUrl is user-controlled, this can lead to injection vulnerabilities.

Basically, in this scenario the Helm chart renders the above Kubernetes ConfigMap. It generates a config.json file and inserts externalUrl directly into JSON using Go templating .Values.externalUrl.

If a user sets this value in values.yaml or via the CLI, it gets rendered without validation or escaping. In this example, if the externalUrl value is not properly sanitized, it could lead to injection attacks. Attackers could potentially exploit this to execute arbitrary code or exfiltrate data.

From an attacker’s perspective, they would identify widely-used Helm charts with known vulnerabilities, often in older versions or charts with complex dependency trees. From there they will try to exploit misconfigurations in RBAC or leverage outdated dependencies to inject their malicious code into these charts. Unsuspecting teams deploy these compromised charts, inadvertently giving attackers a foothold in their clusters.

Real-world CVE: ArgoCD (CVE-2022-24348)

In 2022, a vulnerability in ArgoCD allowed attackers to abuse Helm charts by injecting malicious values that accessed secrets across apps. This supply-chain flaw leveraged Helm’s ability to render arbitrary YAML from user-controlled input, bypassing application scope restrictions.

The vulnerability allowed attackers to inject malicious values into Helm Chart YAML files. ArgoCD, when parsing these user-controlled charts, would render them without adequate validation. This opened the door for attackers to exfiltrate secrets or access sensitive application data across boundaries, effectively bypassing multi-tenancy and scoping controls.

To build a new deployment pipeline in ArgoCD, users can define either:

1. A Git repository or
2. A Helm chart YAML file

both of which contain:

• The metadata and templates needed to deploy Kubernetes resources.
• Dynamic fields and paths that render live infrastructure configurations.

At its core, a Helm chart is just a collection of parameterized YAML templates, and it’s this flexibility that attackers exploited. By supplying crafted chart values, they could inject paths or configurations that referenced other applications’ resources within the same cluster.

This zero-day vulnerability demonstrated how even well-regarded CI/CD tools can be compromised via Helm if proper input sanitization and isolation controls aren’t enforced.

Impact: Unauthorized cross-application access, secret leakage, and potential lateral movement within Kubernetes clusters.

Although this CVE has long since been patched, it serves as a powerful reminder of how complex templating logic in Helm charts can become an attack surface, especially when used in automated deployment systems.

That’s a wrap!

Helm is an incredibly powerful tool, but as Spiderman’s uncle once said, “with great power comes great responsibility.”

As we’ve seen:

• Default values and templates can leak secrets.
• RBAC misconfigurations allow privilege escalation.
• Public charts may be stale, misconfigured, or malicious.
• Don’t blindly trust charts – even from reputable software vendors.
• Finally, bringing your updated packages into a secure repository like Cloudsmith provides users with greater auditing and security capabilities.

Use GitHub Search to inventory the public projects you are working with, run scanning tools like Trivy to check for known vulnerabilities, and enforce controls such as OPA or OPA Gatekeeper to lock down your Helm deployments if charts are breaching security best practices.

Learn more: Check out our on-demand webinar.

More from We Love Open Source

• Introduction to Falco and how to set up rules
• Why Kubernetes is essential for AI and open source projects in 2025
• How curiosity, Kubernetes, and community shaped my open source journey
• Explore the five steps of the FreeDOS boot sequence
• A throwback experiment with Linux and Unix