BreakPoint Drop
BreakPoint

Blog · Security

The XZ Utils backdoor: what every CTO should have learned

In March 2024, a backdoor was found in xz Utils, a near-universal Linux compression library. The attacker had spent two years gaining the maintainer's trust. The lesson is not technical.

Published July 17, 2026 · 6 min read

The XZ Utils backdoor (CVE-2024-3094) is the most sophisticated supply-chain attack on open source to date. The technical details are interesting. The attack vector is the lesson.

What happened

xz Utils is a near-universal Linux compression library. It's loaded by systemd, which is loaded by every major Linux distribution, which is loaded by every server, every container, every CI runner. The maintainer, Lasse Collin, had been the sole maintainer of xz for almost 15 years.

In late 2021, an attacker using the handle "Jia Tan" started contributing minor patches to xz. Over the next two years, they built a reputation as a reliable contributor. They nudged Lasse toward adding new features he didn't have time for. They asked for and eventually received direct commit access. In February 2024, a chain of Jia Tan's commits added a backdoor that, when triggered, would have given remote code execution on any affected system.

The backdoor was caught by accident. Andres Freund, a Microsoft engineer working on PostgreSQL, noticed that SSH logins on a Debian sid machine were using slightly more CPU than expected. He traced the slowness. He found the malicious code. He reported it. CVE-2024-3094 was assigned. The fix shipped within days.

Most production systems were not affected — the backdoor was only in the bleeding-edge distributions. The damage was contained. The lesson was not.

The lesson is not technical

The attacker didn't exploit a code vulnerability. They exploited a maintainer. They exploited a person who had been working on the same project for 15 years, who was tired, who didn't have time to review every patch, who trusted the people who showed up to help.

Lasse Collin had asked for help publicly for years. The xz project was underfunded. The maintainer was doing it for free, on the side, while working a day job. The attacker didn't need to break in. They just needed to be the person who showed up.

This is the bus factor problem, weaponized. A single overworked maintainer is a single point of failure not just for project velocity, but for project security. The XZ Utils attack worked because Lasse was one person, and the attacker spent two years becoming his collaborator.

What could have stopped it

Three things, in order of impact:

  1. Bus factor ≥ 2 from the start. If xz had two active maintainers in 2022 instead of one, Jia Tan's path to commit access would have required convincing two people, not one. The social engineering cost would have been 10x.
  2. Funded maintainership. The Linux Foundation, the OpenSSF, the CNCF, and others have programs that fund critical OSS maintainers. The xz Utils maintainer was not in any of them. A $50K/year grant, with the explicit deliverable of "review 100% of incoming patches within 30 days," would have changed the dynamic.
  3. Reproducible builds + SBOM tracking. Reproducible builds (where the build output can be verified to match the source) would have made the malicious code visible at the binary level. SBOM tracking (a machine-readable inventory of every dependency in your stack) would have made teams aware of the xz dependency so they could have flagged the suspicious commits earlier. Neither is a silver bullet, but both raise the cost of attack.

What a CTO should do this week

You don't need to wait for a coordinated industry response. Three things you can do in an afternoon:

  1. Inventory your top 50 critical dependencies. Open each one's GitHub page. Run git shortlog -sn --all | head -10 in the main branch. Look at the top contributor's share of recent commits. If one person owns >80%, you have a bus factor problem. This is the single most important supply-chain signal you can collect today.
  2. Ask the bus-factor-1 projects: who takes over when this person stops? If the answer is "no one" or "we don't know," that's a critical risk. Either fund the maintainer, find a co-maintainer, or have a fork ready.
  3. Subscribe to security advisories for your top 10. GitHub Security Advisories, the project's own mailing list, Snyk, npm audit. The XZ Utils backdoor was caught because Andres Freund noticed the slowness and reported it. The next one might be caught the same way — if you're watching the right channel.

Get the bus factor for your stack

The /audit walks your org's GitHub repos, scores bus factor, dormancy, and dormancy risk for every dependency. Free, no signup. The one-page memo you can hand to the board.

Run the audit →