GHSA-hr2v-4r36-88hr
Fix: helm/helm@4e7994dGHSA-hr2v-4r36-88hr is a Path Traversal vulnerability in helm.sh/helm/v4. O3 Security confirms whether GHSA-hr2v-4r36-88hr is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment
Real-World Exposure
helm.sh/helm/v4🐹helm.sh/helm/v3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause helm pull --untar [chart URL | repo/chartname] to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the --destination and --untardir flags), rather than the expected output directory suffixed by the chart's name.
Impact
The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory <output dir>/, instead of the expected <output dir>/<chart name>/, potentially overwriting the contents of the targeted directory.
Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.
Patches
This issue has been resolved in Helm v3.20.2 and v4.1.3
A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.
Workarounds
Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the pull --untar flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.
Credits
Oleh Konko @1seal
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | helm.sh/helm/v4 | all versions | 4.1.4 |
| 🐹Go | helm.sh/helm/v3 | all versions | 3.20.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for helm.sh/helm/v4. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update helm.sh/helm/v4 to 4.1.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hr2v-4r36-88hr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hr2v-4r36-88hr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-hr2v-4r36-88hr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hr2v-4r36-88hr in your dependencies?
O3 detects GHSA-hr2v-4r36-88hr across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.