The xz backdoor (CVE-2024-3094) was found by luck and curiosity: a developer noticed slow SSH logins. It showed that a project can be compromised through years of trusted contribution, and that release tarballs can differ from the git source. Those weaknesses remain. Defenses are partial but real.
What happened with xz?
CISA's March 29, 2024 alert reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094. Its advice: downgrade to an uncompromised version such as 5.4.6, hunt for malicious activity and report findings.
Andres Freund's disclosure on the oss-security list explains the discovery. He saw logins with ssh using a lot of CPU, along with valgrind errors, and traced them to liblzma. One timing he reported rose from about 0.299 seconds to 0.807 seconds.
Two details matter. First, the malicious build step was in the release tarballs for 5.6.0 and 5.6.1, and a line in the tarball's build-to-host script was not in the upstream git source. Second, most of the payload sat in obfuscated files in the repository's tests folder that were not used by any test.
OpenSSH does not link liblzma directly. Freund noted that some distributions patch OpenSSH for systemd notification, and libsystemd depends on lzma, which pulled the backdoor into sshd. The payload also ran only under specific conditions and tried to detect some debugging setups.
Why does the problem persist?
Many critical projects have one or two maintainers who are tired and unpaid. A friendly new contributor who helps for a long time is a gift, until the contributor is not who they seem. No tool can verify intent.
The build is the second gap. Users install from tarballs and packages, not from git. If the artifact is not reproducibly derived from reviewed source, review of the repository tells you less than you think.
Third, transitive reach. A compression library most people never chose sat under a service they use every day.
What defenses help?
None is complete.
Compare artifacts to source. Check whether a release tarball contains files that git does not. Reproducible builds make this routine.
Look at project health. The OpenSSF Scorecard runs automated checks, grouped as holistic practices, source risk and build risk, including Code Review, Branch Protection, Maintained, Pinned Dependencies and Signed Releases. A low score is a prompt to look closer, not a verdict.
Track the dependency tree. An SBOM would have answered "do we have liblzma and which version" on March 29.
Watch for odd binary or test data in source trees. Large opaque files in test folders deserve review.
Shrink what runs with privilege. The chain worked because a library loaded into a privileged daemon.
A constructed example
A platform team scores its 40 most critical open source dependencies each quarter. One utility library shows a single active maintainer, no required code review and unsigned releases. The team does not drop it. It pins versions, adds a reproducible build check on the tarball, and sets a reminder to review any release from a new committer. The risk is not removed. It is made visible and watched.
How to check or apply this
- Inventory direct and transitive dependencies with versions, and keep the SBOM current per release.
- Rank dependencies by blast radius: privileged, network facing or widely shared.
- Run Scorecard against the top of that list and record the score and date.
- Prefer source builds or distributions that verify tarballs against tags.
- Delay adopting brand-new releases of critical libraries by a short, fixed window.
- Subscribe to advisories for your key components so a CISA-style alert reaches a named person.
- Fund or contribute to the projects you rely on if you can.
Safeguard can scan dependencies, generate SBOMs and flag risky packages in pull requests. It cannot judge a maintainer's intent.
Quick check
Which xz versions were affected?
CISA reported XZ Utils 5.6.0 and 5.6.1, tracked as CVE-2024-3094. It suggested downgrading to a version such as 5.4.6.
Would a vulnerability scanner have caught it?
Not before disclosure, since there was no known CVE. An inventory would have shown quickly whether you used the affected versions after it was announced.
Sources
- CISA, Reported supply chain compromise affecting XZ Utils (CVE-2024-3094)
- Andres Freund, oss-security disclosure
- OpenSSF Scorecard
Last reviewed: 18 October 2026.
