Helm Chart Secret Leakage: Finding Credentials in Values and Releases

Helm Chart Secret Leakage: Finding Credentials in Values and Releases

Helm is a packaging tool that loves YAML. Secrets love to hide in that YAML—plain values files committed to git, lookup leftovers, default passwords in values.yaml, and release objects stored as Secrets in the cluster.

Bug bounty work here is mostly careful reading plus restrained verification.

Start with what is public

Clone the application's charts when they are public. Grep for:

• password, token, apikey, BEGIN PRIVATE
• valueFrom missing where a Secret should be
• Hard-coded connection strings in ConfigMaps rendered from values
• Example credentials that match production hostnames

A default admin password in values.yaml becomes critical only if you can show it works on a live endpoint in scope. Use your own tenant or a reset flow. Do not spray the password across customer instances.

Watch template helpers that print secrets into ConfigMaps "for convenience," or that base64-encode in Templates and call it encryption. Base64 is transport candy, not protection. If the rendered manifest places a DB password in an env var visible to every process in the pod—and you can read that pod via another bug—chain it clearly.

Hooks and notes templates are sneaky. A post-install Job that echoes the generated password into logs will survive in CI output long after the Job Pod is gone. Read NOTES.txt templates too; some charts print URLs with embedded tokens for "easy onboarding."

Release storage is a second leak surface

Helm 3 stores release metadata in Secrets (or ConfigMaps, depending on config). Anyone who can get secrets in the release namespace can often recover prior values, including credentials that were rotated in git but not in history.

If the program gives you a namespace and a token for testing, list release secrets and inspect only keys you planted. Plant a canary string in a values override you control, upgrade, then show the canary appears in the stored release. That proves the storage issue without exporting unrelated customer data.

CI systems compound this. Chart museum buckets, GitHub Actions logs printing helm get values, and PR previews dumping rendered manifests all leak the same material outside the cluster.

Also check whether helm get manifest or a GitOps render job publishes full YAML to an artifact store with public or wide IAM read. The chart repo may be clean while the pipeline is not.

How to write the finding

Separate three claims:

1. Secret material appears in a place attackers can read (git, UI, API, log).
2. That material is valid or recently valid against an in-scope service.
3. Blast radius: which services, which roles, whether rotation is needed.

Recommend external secret managers, Sealed Secrets or SOPS for git, never committing production values, disabling helm get values in shared logs, and rotating anything that landed in release history.

If you only found a staging default, say staging. Inflating it into "full production takeover" without a live check wastes everyone's time. Helm's chart best-practice notes on secrets are short for a reason: the tool will not save you from a plaintext values-prod.yaml in the repo.