← Back to Blog

The XZ Utils Backdoor: What It Taught Firms About Software Supply Chains

Supply Chain Security

Updated October 2026. First published April 2024.

On March 29, 2024, Andres Freund, a PostgreSQL developer, posted to the oss-security mailing list that the release files for versions 5.6.0 and 5.6.1 of xz, the open-source compression library, contained a backdoor. He hadn't been looking for one. On a machine running Debian's unstable branch, SSH logins were using a lot of CPU and producing errors in valgrind, a memory-checking tool. A login attempt with a nonexistent user name, which should have taken about 0.3 seconds, took about 0.8.

The flaw got the identifier CVE-2024-3094 and a CVSS score of 10, the maximum. It was caught before it reached the stable Linux releases most firms run in production. The lesson for a broker-dealer is mostly about what you run, and how quickly you can find out.

How the Backdoor Worked

The malicious code wasn't in the project's public source repository. It was in the release tarballs, in a build script (m4/build-to-host.m4) that didn't match the version in git, and it pulled hidden payloads out of two files committed as test data. It ran only when the library was built on x86-64 Linux as part of a Debian or RPM package build.

From there it reached the SSH server. OpenSSH doesn't use xz itself, but Debian and other distributions patch it to talk to systemd, and the systemd library depends on liblzma, the library xz builds. Freund wrote that the code sat in the pre-authentication path and "seems likely to allow some form of access or other form of remote code execution."

Who It Reached

Very few production systems. Versions 5.6.0 and 5.6.1 were only weeks old. Debian said no stable versions were known to be affected; the compromised packages were in its testing, unstable, and experimental distributions. Red Hat said no version of Red Hat Enterprise Linux was affected, and that in its ecosystem the packages appeared only in Fedora 41 and Fedora Rawhide. CISA's alert the same day told users to downgrade to an uncompromised version such as 5.4.6 Stable.

How It Got There

The backdoor came from one of the project's own maintainers, the same account that built the release files. Russ Cox's timeline of the attack traces the account named "Jia Tan" from a first small patch on October 29, 2021, through steady contributions. Starting in April 2022, other accounts emailed the project's mailing list complaining that the maintainer was too slow and pressing him to add help. By late 2022, Jia Tan had commit access. Jia Tan tagged and built 5.6.0 on February 24, 2024, and 5.6.1 on March 9.

That's more than two years of patient work by someone who appeared to be a helpful volunteer. In April 2024, the OpenSSF and the OpenJS Foundation warned of similar attempts at JavaScript projects: emails under different names asking to be made maintainers of a popular project. None of those people got privileged access.

What It Means for a Broker-Dealer

You can't review the source of every open-source library your systems use, and neither can your vendors. What you can control is narrower, and it's enough to matter.

  1. Run stable releases in production. The firms that were exposed were running testing or rolling distributions. Waiting for a stable enterprise release costs you new features, and on March 29 it meant you had nothing to patch.
  2. Know what you run. The question that morning was whether xz 5.6.0 or 5.6.1 was installed anywhere. With a current software inventory, that's a query. Without one, it means logging into servers one at a time. The inventory doesn't need to be elaborate, but it has to include containers and developer laptops as well as servers.
  3. Ask your vendors the same question, and ask how fast they answered it. A SOC 2 report won't list the open-source components inside a product. Our post on reading a vendor's SOC 2 report covers what it does show, and what to put in the contract instead.
  4. Treat performance oddities as security signals. The backdoor was found because one engineer didn't accept half a second of unexplained delay.

The xz project has since published clean releases, and its remaining maintainer has posted his own account of the incident and the cleanup.