CVE-2025-32386

What it actually does

A specially crafted chart archive causes Helm to allocate unbounded memory during processing, triggering OOM termination.

Why it matters to the business

Helm operations on affected systems become unavailable, disrupting Kubernetes package deployment and management workflows until the process is restarted or upgraded.

How an attack unfolds

An attacker crafts a malicious chart archive file and supplies it as input to any Helm command that unpacks or inspects charts; the parser consumes all available memory and terminates the Helm process.

How to fix it

Upgrade to a build containing commit e4da49785aa6e6ee2b86efd5dd9e43400318262b or later; rebuild any locally vendored Helm binaries from the patched source.

How to confirm the fix worked

Confirm the running Helm binary reports a version built after commit e4da49785aa6e6ee2b86efd5dd9e43400318262b and re-test with known-malicious archive samples in a controlled environment.

Typical attack path

1. Attacker creates a chart archive engineered to trigger excessive memory allocation
2. Victim runs a Helm command (install, upgrade, lint, etc.) against the supplied archive
3. Helm parser allocates memory without limit and the process is killed by the OS OOM handler

How to detect it

Review process logs and system OOM events for repeated Helm terminations when handling chart archives; correlate with command-line history showing unexpected chart inputs.

What your security team should do

• Immediately upgrade all Helm installations to the fixed commit
• Add Helm binary version checks to CI/CD pipelines and developer workstations
• Restrict untrusted chart archives from being processed on production systems