The release artefact was part of the attack
On 29 March 2024, Andres Freund disclosed a backdoor in upstream xz/liblzma release material. His report described suspicious SSH performance and diagnostic failures that led him to inspect the dependency. The affected release tarballs included 5.6.0 and 5.6.1; part of the malicious build machinery was present in the distributed tarballs rather than solely in the visible source repository.
That distinction is the heart of this case. Reviewing the repository does not establish what a release archive will build. Generated build files, bundled test data and release-only modifications can change the executable result. The trust boundary includes the process that turns reviewed source into distributed software.
A version string is an investigation lead
The Debian security tracker records affected source material and distribution-specific status. NixOS's contemporaneous analysis gives a useful counterexample to blanket version-based claims: it reported that its unstable branch included 5.6.1 but that the malicious build path exited without modifying the library. It still chose to downgrade as a precaution.
This does not make version scanning unhelpful. It means that presence, successful malicious build conditions and exploitable deployment are different findings. A defensible record keeps those stages apart.
| Stage | Evidence needed | Unsafe shortcut |
|---|---|---|
| Source acquisition | Exact archive and provenance | Assuming a repository tag equals the release tarball |
| Build | Distribution recipe, generated files and environment | Assuming every build of a named version is identical |
| Installation | Package identity and installed library | Assuming the machine's package list proves what a process loaded |
| Reachability | Application linkage and relevant configuration | Calling every xz user an exploitable SSH server |
What release engineering should preserve
Keep the downloaded source artefact, its digest, the build recipe and the resulting package identity together. A signature can establish who signed material and whether it changed after signing; it does not independently establish that the signed content is benign.
Where practical, compare release archives with the source tree and document generated additions. Differences are not automatically malicious: release tooling routinely produces files. The useful control is a reviewable explanation of the difference and a way to reproduce it, rather than an assumption that generated files are outside the security review.
FISRO proposes treating unfamiliar binary test fixtures and opaque build-time transformations as review prompts. That is an engineering recommendation derived from this case, not a claim that FISRO discovered another compromised project.
Containment requires an artefact history
For a suspected affected build, identify which systems and images received that precise package, then follow the distribution's incident guidance. Preserve enough evidence to understand where it came from before replacing it. A current clean package does not reconstruct an earlier container digest or a deleted build workspace.
Do not run unknown backdoor demonstrations against production hosts. Package provenance, vendor advisories and controlled artefact examination are the appropriate starting points. If compromise remains plausible, handle the host under the organisation's incident-response process rather than declaring success after a version downgrade.
A different failure from tj-actions
In the later tj-actions compromise, mutable version tags pointed workflows at malicious action code. xz and tj-actions affected different parts of the supply chain, but each undermined a convenient assumption that a familiar label identifies a reviewed execution path.
The comparison supports stronger artefact identity and review. It does not mean commit pinning alone would have prevented xz, or that a reproducible malicious build becomes trustworthy because it is reproducible. Controls need to answer both what ran and why it was accepted.
The downstream linkage made SSH relevant
Freund's disclosure described an x86-64 Linux build path and checks involving the toolchain and Debian/RPM-style packaging environment. The affected SSH relationship was indirect: certain downstream sshd builds linked through libsystemd, which brought liblzma into the process. Upstream OpenSSH's name alone does not establish that dependency chain.
| Population at disclosure | Relevant evidence | Limit of the finding |
|---|---|---|
Upstream 5.6.0 / 5.6.1 tarballs |
Original disclosure's release-only build material and conditions | The version alone does not prove a malicious binary was produced |
| Debian stable bookworm | Debian tracker records not affected for this CVE | Do not transfer the stable-branch finding to testing or sid |
| NixOS unstable's contemporaneous build | Security team's analysis said the malicious path exited | The team still chose a precautionary downgrade |
| A particular SSH deployment | Exact binary, library linkage and package provenance | A package installed elsewhere does not establish this process's load chain |
The distinction prevents a distribution-specific observation becoming a claim about every Linux host. It also explains why a repository review that ignores the distributed tarball misses part of the evidence.
Inspect package provenance without invoking a backdoor test
For Debian packaging, the installed source of the inventory can be queried directly:
dpkg-query -W -f='${Package}\t${Version}\n' xz-utils liblzma5
On an RPM-managed environment, the equivalent package identities can be read using:
rpm -q xz xz-libs
Package names and availability depend on the distribution. These commands do not establish the integrity of a binary or prove that the malicious build conditions were met. Match the full package release with the distribution's own assessment and preserve the installed artefact identity where the incident scope requires it.
For a collected release archive, hashing the file preserves an exact identifier without executing or unpacking it:
sha256sum collected-xz-release.tar.xz
Use the relevant supported hashing tool on the analysis platform. A digest establishes file identity for comparison; it does not establish that the contents are benign. Keep the archive's acquisition record and the build recipe alongside it.
Three supply-chain records describe different weak points
3CX's April 2023 reconstruction traced compromised software consumed by a vendor into its own build environment. SolarWinds' December 2020 disclosure involved trojanised updates delivered through a management-software channel. tj-actions in March 2025 redirected mutable action tags.
xz adds a precise artefact distinction: generated release material and build inputs could change the library without the security reviewer finding an equivalent obvious source-code modification in the expected place. Reproducibility can help explain a build, but reproducing malicious output does not make that output safe.
A useful release review therefore records the source archive, generated differences, build environment, resulting package and process linkage. The component name is an index into that record, not the entire trust decision.