xz-utils Backdoor in liblzma 5.6.0/5.6.1 (CVE-2024-3094)

What to do

1. Check the installed version with xz --version (and dpkg -l xz-utils liblzma5 or rpm -q xz xz-libs).
2. If it reports 5.6.0 or 5.6.1, update to your distribution's fixed package (for Debian, 5.6.1+really5.4.5-1) or a clean upstream release.
3. Search container images, build caches and vendored source trees for xz-5.6.0 or xz-5.6.1 tarballs and rebuild anything built from them.
4. If a host with an affected build ran a public-facing sshd, treat it as potentially compromised: rebuild it and rotate its SSH host keys and credentials.
5. Pin and verify build inputs (prefer reviewed source over release tarballs where practical).

How to check if you are affected or compromised

• Run xz --version; only 5.6.0 and 5.6.1 carried the backdoor.
• Check whether sshd links liblzma: ldd $(command -v sshd) | grep liblzma (true on many systemd-patched builds, which is the precondition for the sshd attack).
• Use the detect.sh script attached to Andres Freund's oss-security post to estimate whether an installed ssh binary is likely vulnerable.
• Unusually slow SSH logins and high sshd CPU usage were the original symptom (sshd -h took about 0.5s instead of about 0.01s).

What happened#

On March 29, 2024, Andres Freund reported on the oss-security mailing list that upstream xz release tarballs had been "backdoored." He was running Debian sid and noticed that SSH logins were using unusual amounts of CPU and that valgrind was reporting errors in liblzma, the compression library from XZ Utils. A failed login took about 0.8 seconds instead of about 0.3, and sshd -h took about 0.5 seconds instead of about 0.01.

The malicious code was in the release tarballs for XZ Utils 5.6.0 and 5.6.1. According to the project's own page, the tarballs were created and signed by co-maintainer Jia Tan. The CVE record describes how the build process extracted a prebuilt object file hidden in a disguised test file and used it to modify liblzma functions. The trigger code was only in the tarballs, not in the Git repository. NVD and Red Hat both score it CVSS 3.1 10.0.

Freund's analysis showed that the build script targeted x86-64 Linux built with GCC and the GNU linker. It activated only during Debian or RPM package builds and likely worked only on glibc. The target was OpenSSH's sshd, which does not use liblzma directly. Many distributions patch sshd for systemd notification, and libsystemd depends on liblzma, which is how the library ended up loaded into sshd.

Who is affected#

Only systems that installed xz 5.6.0 or 5.6.1, which Tukaani lists as released on February 24 and March 9, 2024. Those versions mostly reached rolling and pre-release distributions. Debian's DSA-5649-1 lists testing, unstable and experimental as affected and says Debian stable is not. Red Hat says the packages were only in Fedora 41 and Rawhide and that no version of RHEL is affected.

Do you really need to act?#

Most people do not. The backdoor was found within weeks of being shipped, before it reached stable enterprise releases. No in-the-wild use has been publicly confirmed, and the CVE is not in CISA's KEV catalog as of October 21, 2026. It still rates 10.0 because the modified library could intercept and change data in any software linked against it, including sshd, on systems that met the conditions.

The incident's real weight is as a supply-chain lesson. A co-maintainer with release rights hid the payload in places reviewers rarely look: a disguised test file and build logic that existed only in the release tarballs. If you build from upstream tarballs or keep old base images, it is worth checking that none still contain these versions.

What to do now#

1. Run xz --version, plus dpkg -l xz-utils liblzma5 or rpm -q xz xz-libs.
2. If it reports 5.6.0 or 5.6.1, update. CISA advised downgrading to an uncompromised version such as 5.4.6 and hunting for malicious activity. Debian shipped 5.6.1+really5.4.5-1. Upstream made clean releases on May 29, 2024, and the maintained branch is now 5.8.
3. Scan container images and build caches for the 5.6.0 and 5.6.1 tarballs and rebuild anything built from them.
4. If an affected host exposed sshd to the internet, rebuild it and rotate its host keys and credentials as a precaution.

How to tell if you were hit#

• The version check is the main test. If you never had 5.6.0 or 5.6.1, you were not exposed.
• ldd $(command -v sshd) | grep liblzma shows whether your sshd loads liblzma at all, which was a precondition for the attack.
• Freund's post includes Vegard Nossum's detect.sh, which estimates whether an ssh binary is likely vulnerable.
• None of the sources reviewed here publish a network indicator of use, so host-level version checks are the practical test.

Timeline#

• Feb 24, 2024 — XZ Utils 5.6.0 released with the backdoored tarball.
• Mar 9, 2024 — 5.6.1 released, also backdoored.
• Mar 29, 2024 — Freund's disclosure. CVE-2024-3094 published, CISA alert issued, and Debian DSA-5649-1 released.
• Apr 9, 2024 — XZ Git repositories available on GitHub again.
• May 29, 2024 — Clean upstream releases and review notes v1.0 published.

Vulnerability records

• CVE-2024-3094 · Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Openwall oss-security — Andres Freund: backdoor in upstream xz/liblzma leading to ssh server compromise openwall.com
2. Tukaani — XZ Utils backdoor tukaani.org
3. Tukaani — XZ Utils tukaani.org
4. NVD — CVE-2024-3094 nvd.nist.gov
5. CISA — Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094 cisa.gov
6. Debian — DSA-5649-1 xz-utils security update lists.debian.org
7. Red Hat — CVE-2024-3094 access.redhat.com