CVE-2026-54448: Denial of Service in Trivy Helm Chart Parser via Decompression Bomb

Trivy is an open-source security utility widely deployed in continuous integration pipelines, container registries, and local developer environments to detect vulnerabilities, secrets, and Infrastructure-as-Code (IaC) misconfigurations. The misconfiguration engine scans Helm chart directories and archived packages to identify security policy violations before deployment. To parse compressed Helm charts, the engine must extract raw file content from the standard tape archive format (.tar) wrapped in GNU zip compression (.tgz).

Prior to version 0.71.0, the package responsible for handling Helm chart archives relied on a custom-built file extraction utility. When traversing a targeted filesystem, directory, or artifact repository, the scanner automatically parsed any identified archive files matching Helm patterns. This automated ingestion of untrusted archives exposes a significant attack surface in continuous integration pipelines, where scans are triggered dynamically on unvetted code submissions.

This behavior exposes the underlying application to several resource management vulnerabilities, classified under CWE-409 (Improper Handling of Highly Compressed Data), CWE-770 (Allocation of Resources Without Limits or Throttling), and CWE-789 (Memory Allocation with Excessive Size Value). A remote attacker can exploit these weaknesses by submitting a crafted Helm archive containing highly compressed files. The resulting processing causes complete failure of the execution pipeline, disrupting developers and automation agents alike.

The technical root cause of CVE-2026-54448 lies within the legacy archive parsing code located at pkg/iac/scanners/helm/parser/parser_tar.go. When processing a Helm chart archive, the scanner initialized a standard Go *tar.Reader object to iterate through individual entries within the compressed stream. For each regular file entry detected within the archive header, the unpacker attempted to read and write the data directly to a virtual filesystem.

The critical programming error occurred during the reading phase, where the application executed the Go standard library function io.ReadAll(tr) directly on the uncompressed tar reader stream. Go's io.ReadAll function reads from an io.Reader interface until it encounters an End-of-File (EOF) token. Because the raw data size is unknown beforehand, the runtime dynamically allocates and doubles the capacity of an underlying byte slice to accommodate incoming data.

This behavior represents an unbounded allocation flaw. Gzip compression algorithms allow extremely high compression ratios, enabling an attacker to package massive payloads—composed of highly repetitive sequences like null bytes—into a small archive. When the reader transparently inflates this stream, the Go runtime repeatedly performs heap allocations to expand the byte slice. If the expanded content exceeds the available host memory before reaching an EOF marker, the runtime triggers a panic or is forcefully terminated by the kernel's Out-of-Memory (OOM) killer.

An analysis of the vulnerable source code highlights the risk of reading directly from an untrusted compression stream. In the legacy implementation of parser_tar.go, the application handled standard files without imposing size checks:

// pkg/iac/scanners/helm/parser/parser_tar.go
 
case tar.TypeReg:
    // VULNERABLE: io.ReadAll reads the uncompressed stream until EOF without a size limit
    data, err := io.ReadAll(tr)
    if err != nil {
        return fmt.Errorf("read file: %w", err)
    }
 
    p.logger.Debug("Unpacking tar entry", log.FilePath(targetPath))
    if err := writeFile(targetFS, data, targetPath); err != nil {
        return err
    }

To remediate this, the maintenance team removed parser_tar.go entirely. Instead of attempting to parse archives with a custom loop, they refactored the parent package in pkg/iac/scanners/helm/parser/parser.go to leverage the official Helm SDK archive loader (helm.sh/helm/v4/pkg/chart/loader/archive):

// pkg/iac/scanners/helm/parser/parser.go (Patched)
 
func (p *Parser) ParseArchive(ctx context.Context, fsys fs.FS, archivePath string) ([]Manifest, error) {
	f, err := fsys.Open(archivePath)
	if err != nil {
		return nil, fmt.Errorf("open archive: %w", err)
	}
	defer f.Close()
 
	// SECURE: Offload decompression and extraction logic to the upstream Helm SDK
	files, err := archive.LoadArchiveFiles(f)
	if err != nil {
		return nil, fmt.Errorf("load archive files: %w", err)
	}
 
	for _, file := range files {
		if file.Name == chartutilv2.ChartfileName {
			p.applyChartName(file.Data, "")
			break
		}
	}
 
	return p.render(ctx, files)
}

By utilizing archive.LoadArchiveFiles from the Helm SDK, the system inherits built-in security constraints. The upstream SDK defines hard limits on individual file sizes (for example, limiting metadata and manifest processing to a safe threshold) and restricts overall memory footprints during parsing, preventing decompression bombs from exhausting host resources.

To exploit this vulnerability, an attacker must introduce a crafted Helm chart archive into a directory structure or repository that will undergo a Trivy scanning sweep. The exploitation vector does not require privileged administrative access, merely the ability to commit files to a repository or push to a container registry target that triggers automated scanning pipeline tasks.

An attacker can craft a decompression bomb locally using standard Unix command-line utilities. This involves generating a massive sparse file containing repeating data, compressing it to achieve a high compression ratio, and packaging it within a nested structure. When Trivy attempts to evaluate the file, the scanning process crashes immediately. The logical execution flow is illustrated below:

Because the crash occurs prior to the generation of any scanning reports, an attacker can use this technique to block security compliance checks or prevent automated integration pipelines from verifying any code, creating a significant operational barrier.

The physical impact of exploitation is localized denial of service (DoS). When Trivy encounters the decompression bomb, the memory usage spikes rapidly, consuming all available space on the heap. In environments where resource boundaries are not enforced, this memory leak can degrade neighboring services running on the same host operating system.

In continuous integration and development settings, pipelines are terminated immediately when the runner process is killed. This breaks development workflows and prevents clean builds from completing. If Trivy is run as an admission controller inside a Kubernetes cluster or as a daemonset scanner, the resulting resource starvation can crash container daemons, potentially leading to cascading node instability.

While there is no confidentiality or integrity impact, the vulnerability presents a low attack complexity. Because no user interaction is required beyond the normal operation of a scanning pipeline, the exploitability remains high. The CVSS metrics evaluate this vulnerability with a base score of 6.5 (Medium), emphasizing the impact on application availability.

The primary remediation strategy is upgrading Trivy to version 0.71.0 or newer. This release replaces the custom archive extraction package with safe library calls. If you use containerized scanning agents, update your dockerfiles and Kubernetes configurations to use official tags representing version 0.71.0 or later.

If immediate software upgrading is impossible, several mitigating actions can limit exposure. You can configure Trivy to explicitly ignore tar and zip archive extensions by appending skip arguments to your runtime execution parameters:

trivy fs --skip-files "**/*.tgz,**/*.tar.gz,**/*.tar" /workspace

Additionally, enforce memory resource limits on the runner environments executing security audits. For instance, running the tool under Docker with memory constraints prevents the process from consuming more than its allocated threshold, isolating the memory impact and protecting the host machine from exhaustion:

docker run --memory="2g" aquasec/trivy:0.70.0 fs /workspace