A single command—helm install, helm template, even a GitOps controller pulling a chart—can now crash a server or CI runner if it unpacks a rigged chart archive. The vulnerability, tracked as CVE‑2025‑32386, lets an attacker craft a tiny Helm chart file that expands into a gigabytes‑sized payload, exhausting memory and killing the process. The fix, released in Helm 3.17.3 in April 2025, adds hard limits on decompressed sizes, and Microsoft has flagged Azure Linux as definitely affected. But because Helm hides inside everything from developer laptops to cloud shells, the real work is figuring out where you’re exposed—and patching before someone triggers a denial of service.
What changed: How the chart bomb works and how Helm stops it
Helm charts are gzipped tarballs—.tgz files—that contain YAML templates, metadata, and sometimes extra assets like JSON schemas. When you run any Helm command that inspects or deploys a chart, the client decompresses the entire archive into memory. Before version 3.17.3, Helm did not enforce an upper limit on how large that decompressed data could be. An attacker who knew this could pack a chart with highly compressible patterns (all zeros, repeated strings, carefully structured tar entries) so that a few kilobytes on disk inflate to many gigabytes in RAM. The moment Helm tries to read that, the operating system’s OOM killer shuts it down—or the process simply panics.
Helm’s maintainers closed the door by introducing two new guardrails that ship with v3.17.3:
- MaxDecompressedChartSize defaults to 100 MiB—the total size of the expanded chart cannot exceed this.
- MaxDecompressedFileSize defaults to 5 MiB—no single file inside the chart can decompress to more than this.
If either threshold is crossed, Helm immediately returns an error instead of attempting a catastrophic allocation. The change was committed alongside a fix for a separate recursive JSON schema parsing bug (CVE‑2025‑32387) that could also crash Helm. Both fixes landed in the same release.
Who’s really affected: It’s not just Azure Linux
Microsoft’s Security Response Center advisory for CVE‑2025‑32386 says Azure Linux “includes this open‑source library and is therefore potentially affected.” That’s accurate for the distro, but it would be a mistake to read it as “no other Microsoft product is vulnerable.” Software supply chains are messy. Helm and its Go library are embedded in:
- Developer workstations—any machine with the
helmCLI installed. - CI/CD runners—GitHub Actions, Azure DevOps agents, Jenkins workers that run
helm lintorhelm template. - GitOps controllers—Flux, Argo CD, and other operators that fetch and render charts automatically.
- Cloud‑managed shells and images—Azure Cloud Shell (which runs on Azure Linux and includes Helm), AKS node images, Marketplace VM images, and even WSL2 kernel images that ship developer tooling.
- Internal chart repositories—registry platforms like Azure Container Registry or Harbor that index and inspect charts server‑side.
Microsoft has committed to publishing machine‑readable CSAF/VEX attestations and updating CVE mappings if additional products are found to be affected. But at this moment, the only Microsoft artifact with a confirmed hit is Azure Linux. For everything else, you must run your own inventory. Assume nothing until you’ve checked.
How we got here: A missing safety net
Helm has been the Kubernetes package manager standard for years, and chart loading code has always been trusted to handle arbitrary archives. The CVE‑2025‑32386 weakness wasn’t a new feature—it was an absence of defensive programming. Decompression bombs are a well‑known attack class, but Helm’s loader never implemented size checks, relying instead on the OS to cry uncle when memory ran out.
The issue was reported and fixed as part of a coordinated disclosure cycle in April 2025. Helm’s GitHub repository shows the exact pull request that added MaxDecompressedChartSize and MaxDecompressedFileSize variables and wired them into the archive extraction path. Distribution maintainers for SUSE, Red Hat, and others mirrored the fix quickly, and Microsoft’s Azure Linux team followed suit.
What to do now: A prioritized checklist
The patch for CVE‑2025‑32386 is a binary‑level fix—install Helm 3.17.3 or later. But because Helm is scattered across so many touchpoints, a one‑shot upgrade rarely covers everything. Use this checklist to systematically close the hole.
1. Upgrade Helm everywhere you control
Start with the obvious: developer laptops, CI agents, operator containers. Run helm version to confirm the release tag shows v3.17.3 or newer. If you use a package manager (apt, brew, choco), pull the latest. For custom images that bundle Helm, rebuild with the updated binary.
2. Inventory Microsoft and third‑party artifacts
For Azure Linux, Microsoft’s attestation is a direct call to action—patch the distro packages now. If you run Azure Cloud Shell, those sessions also get the updated Helm when the image is refreshed. For AKS node images, Marketplace VMs, or WSL2 kernels, consult Microsoft’s CSAF/VEX feeds as they are published, or run a local scan: search for the helm binary or the helm.sh/helm/v3 Go module inside container layers and package manifests.
3. Add compensating controls in automation
Even after patching, defense in depth matters:
- Sandbox Helm processes with memory limits (cgroups, Docker --memory, Kubernetes resource limits) so an unexpected large chart can’t take down a node.
- Scan charts at ingestion—your chart repository should reject archives whose decompressed size exceeds policy. Tools like tar and custom scripts can preview the uncompressed size before Helm ever sees the file.
- Restrict chart sources—require signed charts and provenance checks. Only allow curated, trusted repositories in production pipelines.
4. Monitor for OOM symptoms
Set up alerts for OOM‑killed processes, Helm crashes, or sudden memory spikes on CI runners and operator hosts. If you see the pattern after an upgrade, it’s often a sign that someone is hitting the new limits with a legitimate chart—so you’ll need to intervene rather than ignore it.
5. Handle legitimate charts that exceed the new limits
Helm’s 100 MiB/5 MiB defaults broke some real‑world charts immediately. If you maintain charts, move large binaries to container registries and reference them by image digest instead of embedding them in the chart. If you consume third‑party charts that legitimately need more room, you can:
- Request an update from the chart maintainer to slim down the package.
- Fork and repackage the chart yourself, stripping the large files into a sidecar mechanism.
- As a last resort, build a custom Helm client with higher limits—but understand this reopens the vulnerability. Only do it in controlled, trusted environments where chart sources are fully vetted.
6. Lean on SBOMs
Software bills of materials make it much easier to answer “which images contain Helm?” If you maintain SBOMs for your containers and VM images, a simple grep against the SBOM’s package list will tell you where the vulnerable versions live. Microsoft’s eventual machine‑readable VEX data will automate this further, but while that rollout is ongoing, internal SBOMs are your best inventory tool.
Outlook: A safer chart ecosystem with growing pains
Helm 3.17.3’s size limits are a textbook example of a security fix that improves defense at the cost of some operational convenience. The breakage is real, and it will take time for chart maintainers to adapt. Expect follow‑on patches that may tune the default limits or add configuration knobs for operators. In the meantime, the immediate risk of an untrusted chart taking down your CI/CD pipeline or a production GitOps controller is significant enough to prioritize the upgrade everywhere. Keep an eye on Microsoft’s CSAF/VEX updates if you run Azure services—the initial Azure Linux disclosure is just the first tile in a larger product mapping. And if you haven’t already, start treating Helm charts with the same scrutiny you apply to container images: scan them, sign them, and never unpack one from an unknown source without limits in place.