xz backdoor timeline: what defenders should learn from it

The xz backdoor, CVE-2024-3094, was planted in versions 5.6.0 and 5.6.1 of the xz compression library after more than two years of building trust with its maintainer. Engineer Andres Freund found it on 28 March 2024 and warned publicly on 29 March. Defenders should treat trust, build artifacts and odd performance as attack surface.

What is the dated timeline?

Dates below follow Russ Cox's compiled timeline, which draws on the project history and public reports.

• 29 October 2021. An account named Jia Tan sends a first, harmless patch to the xz-devel mailing list.
• 7 February 2022. The first commit authored by Jia Tan is merged.
• April to June 2022. Other accounts press the maintainer for faster progress. The maintainer says he has limited capacity and that Jia Tan is helping.
• 28 October 2022. Jia Tan is added to the project's GitHub organization.
• 30 December 2022. Jia Tan merges commits directly, which confirms commit access.
• 22 June 2023. Changes using the ifunc mechanism are merged. They provide a hook the backdoor later used.
• 23 February 2024. The backdoor binary is merged, hidden in test input files.
• 24 February 2024. Version 5.6.0 is tagged, and its release tarball carries a modified build file.
• 4 March 2024. Red Hat distributions report Valgrind errors in the library.
• 9 March 2024. Version 5.6.1 is tagged and published.
• 28 March 2024. Freund privately notifies Debian and a distribution security list. Red Hat assigns CVE-2024-3094.
• 29 March 2024. Freund posts a public warning to oss-security.

How was it found?

Freund's report describes symptoms on Debian unstable systems over several weeks. SSH logins used a lot of CPU, and a timing test of a failed login went from about 0.30 seconds to about 0.81 seconds. Valgrind also reported errors. He concluded that the upstream repository and the tarballs had been backdoored. He wrote that 5.6.0 and 5.6.1 had not yet been widely adopted by distributions, and mostly appeared in pre-release versions.

CISA's alert advised downgrading to an uncompromised version, naming XZ Utils 5.4.6 Stable as an example, hunting for malicious activity, and reporting positive findings.

What was affected?

Versions 5.6.0 and 5.6.1. The release tarballs contained a malicious line in a build file that was not in the Git repository, and obfuscated test files holding most of the exploit were committed upstream. Systems that patched sshd to link libsystemd were the exposed ones, including Debian, Ubuntu and Fedora builds according to the timeline's author. Gentoo was not affected.

What should defenders learn?

Maintainer load is a security issue. A single tired maintainer under pressure became the way in. Treat projects with one maintainer as concentrated risk.

Release tarballs can differ from the source. Building from Git is a check. Arch Linux changed its 5.6.1 package to build from Git.

Test files can hide payloads. Binary blobs in tests get little review.

Fewer links, smaller blast radius. The change that stopped linking liblzma into libsystemd reduced exposure.

Odd behavior deserves a look. A half second of extra login time started the discovery.

Know where a library lives. An inventory of components, including those in container layers, turns the question "do we run xz?" into a search. You can see what that looks like below.

Open the full version at /demos/sca-dependency-inventory.

What to do

1. Build a searchable inventory of components for every image and service.
2. Flag dependencies with one active maintainer and decide what you do if they leave.
3. Compare release artifacts with the tagged source for critical libraries where you can.
4. Add alerts for sudden changes in login latency or CPU on bastion hosts.
5. Write a runbook for "a core library was backdoored" and test the search step.

Quick check

Sources

• Russ Cox, Timeline of the xz open source attack
• Andres Freund's report on oss-security
• CISA alert on XZ Utils, CVE-2024-3094

Last reviewed: 18 October 2026.