GHSA-q3fv-x8vg-qqm4
Trivy: Helm chart tar bomb causes OOM via unbounded io.ReadAll in parser
Blast Radius
github.com/aquasecurity/trivyReal-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
Summary
When Trivy scans a Helm chart archive (.tgz), its custom tar unpacker reads each entry with io.ReadAll(tr) and no size limit. An attacker who can place a malicious .tgz file in the scanned path can craft a small compressed archive that decompresses to gigabytes, causing the Trivy process to be killed by the OS OOM killer.
Affected configurations
Exploitation requires the attacker to place a crafted .tgz file in a location that Trivy will scan as a Helm chart. This applies to the following scan targets:
| Command | Condition |
|---|---|
trivy config <dir> | Directory contains a crafted .tgz Helm chart (misconfiguration scanning is always enabled) |
trivy filesystem --scanners misconf <dir> | Directory contains a crafted .tgz Helm chart and --scanners misconf is explicitly enabled |
trivy image --scanners misconf <image> | Image contains a crafted .tgz Helm chart and --scanners misconf is explicitly enabled |
Realistic scenarios include:
- A CI pipeline that runs
trivy config .on a repository where a contributor can submit a pull request containing a crafted chart archive. - A pipeline that scans a container image with
--scanners misconf, whose build context includes untrusted.tgzfiles.
Impact
An attacker who satisfies the conditions above can exhaust all available memory on the host running Trivy. The OS OOM killer will terminate the Trivy process and may affect other processes sharing the same host or CI runner.
The practical impact in CI environments is denial of service: the scan fails, the pipeline is blocked, and repeated submissions re-trigger the same condition. Cloud CI runners may also incur additional costs for consumed resources.
There is no impact on confidentiality or integrity of the scanned system.
Patches
Fixed in Trivy v0.71.0 (#10718). The custom tar unpacker was replaced with archive.LoadArchiveFiles from the official helm.sh/helm/v4 SDK, which enforces per-entry and total size limits and validates archive structure. Users should upgrade to v0.71.0 or later.
Workarounds
If upgrading is not immediately possible:
- Set a memory limit (cgroup/container) on the Trivy process to bound the blast radius.
- Use
--skip-dirsto exclude directories containing untrusted Helm chart archives from the scan. - Avoid scanning repositories or images with untrusted
.tgzfiles.
Credits
Reported by @jamesgol.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/aquasecurity/trivy | all versions | 0.71.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/aquasecurity/trivy. 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 github.com/aquasecurity/trivy to 0.71.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q3fv-x8vg-qqm4 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-q3fv-x8vg-qqm4 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-q3fv-x8vg-qqm4. 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-q3fv-x8vg-qqm4 in your dependencies?
O3 detects GHSA-q3fv-x8vg-qqm4 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.