A denial-of-service vulnerability in Helm, the widely used Kubernetes package manager, can crash developer machines and CI/CD pipelines when processing a malicious chart containing a specially crafted JSON Schema. Microsoft has confirmed that its Azure Linux distribution ships the affected open-source library and is therefore potentially vulnerable to this flaw, tracked as CVE-2025-32387. The Helm team has released version 3.17.3 to patch the issue, and all users—especially those running Azure Linux or consuming charts from untrusted sources—should upgrade without delay.

The Vulnerability: Helm’s JSON Schema Parser Crash

The flaw lies in how Helm resolves $ref references within JSON Schema files embedded in charts. Helm uses these schemas to validate chart values, but a recursive or deeply nested chain of references can exhaust the call stack, leading to a crash. The Helm process panics with a stack overflow, causing an immediate denial of service.

The Helm maintainers addressed the problem by imposing recursion limits and adding defensive checks in the JSON Schema resolver. In Helm v3.17.3, any chart with a pathological $ref chain will now trigger a safe parser error instead of crashing. All Helm 3.x releases prior to this fix are considered vulnerable.

Multiple vulnerability databases have given the issue a CVSS score of around 6.5, classifying the impact primarily as availability loss. While the attack requires user interaction—someone must download and inspect the malicious chart—it can be triggered remotely by simply fetching a chart from a public repository, making it a credible threat for automated pipelines and developer environments.

Microsoft’s Response and What It Covers

In a concise update to its Security Response Center (MSRC) guide, Microsoft stated: “Azure Linux includes this open-source library and is therefore potentially affected by this vulnerability.” The company also noted its commitment to transparency through machine-readable CSAF/VEX attestations, which it began publishing in October 2025. Microsoft has promised to update the CVE entry if other products are found to include the vulnerable component.

The statement is product-scoped: it confirms Azure Linux images maintained by Microsoft carry the vulnerable library. It does not assert that other Microsoft products—such as WSL kernels, Azure Marketplace VM images, AKS node images, or Windows-hosted tools that bundle Helm—are free of the issue. Operators should treat the absence of an attestation for other products as “unknown” until verified by Microsoft or their own inspection.

Who’s at Risk: Developers, CI/CD, and Azure Users

The risk profile varies:

  • Developers running Helm locally on Windows, macOS, or Linux: If you ever run helm install, helm template, or helm lint against a chart from an untrusted source, a malicious schema could crash your Helm client. This disrupts your workflow and, in worst cases, could be chained with other exploits if the crash is mishandled.
  • CI/CD pipelines: Automated builds that validate, package, or deploy charts are prime targets. A single crafted chart pushed to a repository can knock out an entire pipeline fleet, delaying releases and wasting compute resources.
  • Azure Linux users: If you run workloads on Azure Linux (the container-optimized OS used in AKS, Azure Arc, and other services), your nodes may include a vulnerable version of Helm. While the primary attack vector is through chart ingestion, the presence of the vulnerable library means any Helm invocation on those systems is a potential crash point.
  • Other Microsoft-supplied images: Until Microsoft releases attestations or you perform your own checks, treat any Microsoft-distributed Linux images or tooling that might include Helm as potentially affected.

Why This Matters: The Path to Discovery

Helm has become the de facto standard for packaging and deploying applications on Kubernetes, and its chart ecosystem is vast. Charts are often shared between teams and sourced from public registries like Artifact Hub. JSON Schema validation is a core part of ensuring chart correctness, making the parser an attractive target.

The vulnerability echoes similar issues seen in other parsers that handle recursive structures without bounds. Attackers can construct a schema with a $ref that points back to itself or to another schema that in turn references the first, creating a loop. Without safeguards, the parser follows these references endlessly until the stack overflows. The fix is simple—check the depth—but the prevalence of Helm in modern infrastructure makes the impact broad.

Microsoft’s disclosure via CSAF/VEX marks a step forward in transparency for open-source components it ships. However, the phased rollout means coverage is incomplete. For now, Azure Linux is the only Microsoft product with a “confirmed” flag; the rest are in a gray area.

Your Action Plan: Patching, Scanning, and Hardening

Here’s what to do right now to protect your systems:

1. Upgrade Helm Everywhere

Check the version of Helm on all your machines and runners:

helm version --short

If it’s anything older than v3.17.3, upgrade immediately. Use your package manager or the official binary release from helm.sh:

# Example for Linux/macOS
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh --version v3.17.3

On Windows, download the installer from the Helm GitHub releases page or use a package manager like Chocolatey:

choco upgrade kubernetes-helm --version=3.17.3

2. Harden Your CI/CD Pipelines

  • Scan charts before ingestion: Add a step in your CI pipeline to search for $ref patterns in JSON Schema files. For example:
    bash find . -type f -name "schema.json" -exec grep -l '"$ref"' {} \;
  • Sandbox Helm operations: Run Helm in ephemeral, containerized environments with minimal privileges. Avoid mounting critical host files or secrets into the same context.
  • Block untrusted sources by default: Configure your chart repositories to only pull from approved registries. Use tools like Harbor’s vulnerability scanning or OPA policies to reject charts that don’t pass inspection.

3. Patch Azure Linux and Monitor Microsoft Updates

If you’re using Azure Linux, apply the latest updates from Microsoft’s repositories. Microsoft typically releases security fixes through its standard update channels; consult the Azure Linux documentation for the specific update command (often tdnf update or yum update for older versions).

Subscribe to the MSRC security update guide and Microsoft’s VEX/CSAF feeds to get notified if other products are added. You can find the machine-readable documents linked from the CVE page.

4. Inventory and Verify Other Microsoft Artifacts

Don’t assume safety for WSL, Marketplace VMs, or AKS node images based solely on the Azure Linux attestation. For each artifact:

  • Log into the image and run helm version.
  • Check any embedded Helm binaries in cloud-init scripts or container entrypoints.
  • If you can’t verify directly, treat the artifact as vulnerable until Microsoft publishes a confirmation.

The Road Ahead: Wider Microsoft Impact and VEX Expansion

Microsoft’s adoption of security attestations is a welcome development, but it’s still early. As the phased rollout continues, expect more product families to receive machine-readable VEX statements. The company has explicitly stated it will update CVE-2025-32387 if it discovers the vulnerable component in other offerings. That means the scope could widen beyond Azure Linux—stay vigilant.

The Helm project itself will likely issue further hardening to prevent similar recursive parsing bugs. For now, the v3.17.3 update is the definitive fix, and applying it should be your top priority. The combination of patching, pipeline hygiene, and vendor monitoring will keep your Kubernetes infrastructure safe from this low-hanging-but-disruptive attack vector.