Introduction

Syft is an open-source CLI tool and Go library, developed by Anchore, that generates a Software Bill of Materials (SBOM) from container images and filesystems. Think of it as a tool that produces a detailed "ingredient list" of everything inside your software. An SBOM is a formal, structured list of all the components, libraries, and packages that make up a piece of software, including their versions and licenses. It's essentially an inventory of your software's dependencies. When you point Syft at a container image (like a Docker image) or a directory, it scans it and identifies every package and library present. It can then output that inventory in a variety of standardized formats so other tools can consume it.

Its broad adoption speaks for itself: Docker, Grafana, Cilium, Helm, OpenTelemetry, Bitwarden, and hundreds of other major open-source projects rely on it, and it has been embedded as a library inside tools like Kubescape, ThreatMapper, and GoReleaser. With software supply chain security becoming a regulatory and industry priority, Syft fills a critical role by making it practical to know exactly what's inside your software.

Vulnerability

Syft's file: source handler contains a decompression bomb vulnerability in the way it processes compressed archives. When Syft is pointed at a compressed file, it extracts the entire contents to a temporary directory before scanning, and it does so without enforcing any limit on how large the extracted output can be. A carefully crafted archive can therefore be tiny on disk but expand to an enormous size during extraction, consuming all available disk space, saturating I/O, and ultimately crashing or hanging the system. The core issue lives in syft/source/filesource/file_source.go, inside the unarchiveToTmp function (around lines 260–292). At line 282, a bare io.Copy() call streams the decompressed content directly to disk with no size check, no threshold, and no early exit:

This single unbounded copy is all it takes. An attacker can construct a decompression bomb — a file where the compression ratio is extreme, such as one megabyte of compressed data expanding to hundreds of gigabytes of output  and Syft will faithfully extract every byte of it.

Attack vector

The vulnerability is reachable through any code path that causes Syft to process an attacker-influenced archive via the file: scheme. The most direct route is simply invoking syft scan file:/path/to/malicious.tar.gz on a file the attacker controls, but in practice the more dangerous scenarios are those where Syft operates autonomously. 

In CI/CD pipelines, it is common to scan pull request artifacts, freshly built container images, or incoming dependency packages automatically; an attacker who can introduce a malicious archive into that pipeline triggers the vulnerability without any further human interaction. 

Similarly, package registries and software supply chains represent a high-value vector: a malicious package published to a public or internal registry can cause every downstream Syft scan of that package to detonate the bomb. Finally, any web application or API that accepts user-uploaded archives and passes them to Syft for scanning is directly exploitable by any user with upload access.

The attack flow itself is straightforward. Syft's fileAnalysisPath() detects that the input is a recognized archive format and hands it off to unarchiveToTmp(), which begins streaming decompressed bytes to $TMPDIR via the unbounded io.Copy(). There is no checkpoint, no quota and no watchdog, the extraction simply continues until either the archive is fully consumed or the filesystem runs out of space, at which point the host system is degraded or unresponsive.

Inconsistent security implementation

What makes this vulnerability particularly striking is that the Syft codebase already contains a purpose-built defense against decompression bombs, it simply isn't applied everywhere. In internal/file/copy.go, the developers defined a safeCopy() function that wraps io.Copy() with an io.LimitReader, capping the amount of data that can be extracted from any single file at two gigabytes. If that limit is reached, the function returns an explicit error identifying the event as a potential decompression bomb attack:

This function is used correctly in the internal file traversal paths. Both internal/file/tar_file_traversal.go and internal/file/zip_file_traversal.go call safeCopy() when reading archive entries, meaning those code paths are protected against exactly this class of attack.

The problem is that the file: source handler in syft/source/filesource/file_source.go bypasses this protection entirely, using a raw io.Copy() instead. The fix already exists in the repository, it just was not consistently applied. This is not a case of an unknown attack class or a missing mitigation strategy; the developers clearly understood the risk and built a solution for it. The vulnerable code path simply never received the same treatment, leaving a gap where the established pattern was not followed.