Skip to content
>_ITDITDWeb Security Platform

History

#XZ Utils#supply chain#OSS#dependencies

The XZ Utils backdoor (CVE-2024-3094) — when trust itself was the target

In 2024, a backdoor was found in xz/liblzma — planted by someone who spent years earning the maintainers' trust, caught just before stable by one engineer's 'something feels slow'. How trust was the target, and the supply-chain lessons.

Published 2026-06-07 Updated 2026-06-07 4 min read

Revisiting a landmark event for the lessons that still apply to your operations.

2024
discovered
years
spent building trust
trust
what was targeted
by a hair
caught just before stable

What happened

The library was under-maintained, long carried by a single person. Another individual contributed steadily, built up trust, and eventually gained co-maintainer status. Then, woven into ordinary updates, they staged in a mechanism allowing unauthorized external access under specific conditions.

What was targeted wasn't a hole in the code, but the assumption that "a trusted person's legitimate update" is safe.

① Under-maintained, one exhausted person carrying it
② Another contributes steadily and becomes "trusted" (years)
③ Gains co-maintainer privileges
④ Stages a backdoor into ordinary updates, in steps
The attack advanced through 'building trust', not 'technique'. Each step looked like legitimate activity.

People and trust were the target

Firewalls and patches don't stop this. OSS maintainers run on goodwill and volunteer time, and that overload and isolation became the entry point. It showed that the health of the ecosystem itself is a security matter.

How it was caught — not ignoring "something feels slow"

The break came when an engineer, mid-unrelated work, noticed a login path was "clearly slower than before" and the benchmark numbers looked off — and chased it to the root instead of ignoring it. As a result, the world was spared before it spread widely into stable releases.

"Something feels off" is the best detector. Here, it literally saved the world.

Timeline

  1. years prior

    The attacker contributes steadily, building maintainer trust.
  2. early 2024

    A backdoor is staged into legitimate updates, in steps.
  3. 2024-03

    An engineer chases a "slow" anomaly; it's caught and disclosed just before stable.

Lessons that still apply

1

Minimize dependencies

Fewer libraries means fewer parties to trust. Don't add "because it's convenient."

2

Pin versions, watch changes

Lockfiles catch unexpected updates; look at the content of important dependency changes (who, what).

3

Improve build reproducibility

The more the same input yields the same artifact, the easier quiet tampering is to spot.

4

Never ignore an anomaly

"Feels slow / off" is the best detector — here it saved the world. Build a culture of chasing small anomalies to the end.

5

Respect and support maintainers

The health of the OSS you depend on is, in the end, your own safety. Overload and isolation are the entry point.

FAQ

QWhat made the XZ Utils case unusual?
A

It targeted people and trust, not a code bug. The attacker spent years becoming a trusted OSS maintainer and slipped a backdoor in as a legitimate update — hard to stop with technical controls alone.

QHow was it discovered?
A

An engineer, mid-unrelated work, noticed a login path was 'clearly slower than before' and the benchmark numbers looked off — and chased it to the root instead of ignoring it. As a result it was caught just before spreading widely into stable releases.

QWhat can an indie developer do?
A

Minimize dependencies, watch the provenance and content of updates, pin versions so unexpected changes are detectable, improve build reproducibility, and never ignore a 'something's off' feeling.