Were you ever exposed to the xz backdoor? A short audit checklist

To check xz exposure, find every host, container image and build that ever contained xz or liblzma 5.6.0 or 5.6.1, then confirm whether it was a rolling or pre-release distribution. The public reports say most stable releases never shipped those versions. Your answer should rest on inventory, not memory.

What was affected

CISA's 29 March 2024 alert names XZ Utils 5.6.0 and 5.6.1 under CVE-2024-3094 and advises downgrading to an uncompromised version such as 5.4.6. Andres Freund's original report says distributions had mostly not yet shipped these versions, and where they had, it was usually in pre-release builds.

That is a reason for calm, not for skipping the audit. Developer laptops, test images and long-lived containers often track newer packages than production.

Step 1: list where xz could be

Think in layers. Each has its own way to look.

• Hosts: query the package manager for the installed xz and liblzma versions.
• Container images: scan image layers, not only the running base. An old layer can hold a bad version even if the final one does not.
• Build agents and CI runners: these install packages on demand and are often rebuilt rarely.
• Developer machines: especially anyone on a rolling release or a fresh preview of an operating system.
• Vendored or statically linked copies: a binary can embed liblzma without any package record.

Step 2: check the version

On a Debian family host, for example:

dpkg -l | grep -E 'xz-utils|liblzma'
xz --version

Freund's post attached a script, detect.sh by Vegard Nossum, to check whether an sshd binary is likely affected. Read any script before you run it, and run it on a copy of a test system first.

Step 3: decide what exposure means

The reported mechanism needed several things at once: a particular architecture and toolchain, a package build, and an sshd that loaded liblzma through a patched dependency chain. A host with 5.6.0 installed is therefore not automatically compromised, but you should treat it as a finding and fix it.

If a host was both exposed and reachable over SSH from untrusted networks, escalate it. The report says the code appeared to be built to give some form of pre-authentication access, though the author had not fully worked out what it checked.

Step 4: record what you learn

The real output of this exercise is not a clean bill of health. It is a record: which systems you checked, how, and when. Keep it with your incident notes. Next time, an inventory with component versions per image and per build turns a day of searching into a query.

Where Safeguard fits

Safeguard generates SBOMs and runs dependency scanning, so you can search components across projects by name and version. You can try a free scan at gold.safeguard.sh/scan. Hosts that no scanner sees still need the manual steps above.

Quick check

Sources

• oss-security: backdoor in upstream xz/liblzma
• CISA alert on CVE-2024-3094

Last reviewed: 19 October 2026.