xz backdoor: a checklist to test whether your org would catch it

Would your organization have caught the xz backdoor? Use this checklist to find out. It covers comparing release tarballs with source control, watching for small performance changes, knowing which libraries your critical services load, and delaying fresh releases of low-level dependencies. Detection depended on an engineer noticing a half-second delay.

What happened, briefly?

CISA's alert of 29 March 2024 says XZ Utils versions 5.6.0 and 5.6.1 contained malicious code, tracked as CVE-2024-3094, and advised downgrading to an uncompromised version such as 5.4.6. The NVD record describes malicious code in the upstream tarballs, extracted through a disguised test file during the build.

Andres Freund, who found the problem, wrote on the oss-security list that he noticed SSH logins using unusual CPU and valgrind errors involving liblzma over several weeks on Debian unstable. In his test, a login took 0.807 seconds with the affected library versus 0.299 seconds before. He noted that part of the backdoor existed only in the release tarballs, in a line in m4/build-to-host.m4 that was absent from xz's git repository. The path to sshd ran through libsystemd, which several distributions link into sshd and which loads liblzma.

This is a story about a maintainer ecosystem that was exploited, and about one engineer's careful attention. Nobody who consumed those releases was careless for trusting a normal upstream.

The checklist

Source and build

• Do you compare release tarballs with the tagged source for dependencies you build yourself? A difference like the one Freund found is the kind of thing a diff of tarball contents against the tagged source can surface.
• Do you review binary or opaque files that arrive in a dependency update, including test fixtures? The repository held obfuscated test files, which looked ordinary at a glance.
• Do you prefer building from a repository to building from a convenience tarball when the project allows it?

Inventory

• Can you list, for a production server, every shared library that sshd loads at runtime, not only the packages you installed on purpose? The path here was indirect.
• Can you answer within an hour "where do we run xz 5.6.0 or 5.6.1?" An SBOM for hosts and images makes this a query, not an investigation. Test it with a drill.

Change control

• Do low-level libraries in production get a short soak period in a non-production environment before you adopt a new release? The affected versions had not been widely integrated by distributions, which limited the exposure.
• Is there an owner who reads release notes for the dozen packages everything else depends on?

Detection

• Do you baseline authentication latency and CPU for critical services, and does anyone look when they move? The backdoor was found by someone who looked.
• Do you have a way to run tests under a tool like valgrind or an equivalent for critical builds, and to treat new errors as a signal?
• Do you subscribe to distribution security lists and the CISA alerts, and is there a named person who triages them the same day?

Response

• If a CVE appears in a core library tonight, can you downgrade, redeploy and verify without a heroic effort? CISA's advice was to downgrade and hunt for malicious activity.
• Do you know how to report findings to your distribution and to CISA?

Where tooling helps and where it does not

Dependency inventory and malicious-package detection help with the where-do-we-run-it question. Reachability analysis helps with ordinary vulnerabilities, but a backdoor in a library that loads into a daemon is a different problem. Do not expect any scanner to have caught this one before disclosure; the checklist above is mostly about speed of response and about adding friction to a repeat.

Open the zero-day watch demo

What to do

1. Run the inventory drill: find every xz version across hosts and images.
2. Add a diff of tarball against tagged source for dependencies you build.
3. Flag opaque or binary files in dependency updates for review.
4. Add a soak period for new releases of low-level libraries.
5. Baseline login latency and CPU on critical services and alert on drift.
6. Name an owner for distribution and CISA advisories.
7. Rehearse a downgrade and redeploy for a core library.

Quick check

Sources

• CISA alert on XZ Utils CVE-2024-3094
• Andres Freund on oss-security, 29 March 2024
• NVD API record for CVE-2024-3094

Last reviewed: 18 October 2026.