XZ Supply-Chain Compromise: How the liblzma Backdoor Was Planted and How It Stayed Hidden

In early 2024, the open-source world got a reminder that supply-chain attacks do not always arrive as a dramatic hack. Sometimes they arrive as a polite contributor, a helpful patch, and two years of patience.

The XZ Utils compromise, tracked as CVE-2024-3094, was a backdoor planted in a widely used compression library. Not in a flashy application. Not in a trendy npm package. In infrastructure so boring that most Linux systems depend on it without ever thinking about it.

That is what made it dangerous. xz/liblzma sits below a lot of other software. If the malicious releases had spread further, attackers could have influenced SSH authentication on affected systems. That would have been a very un-boring outcome from a very boring dependency.

A compromise built over years, not minutes

Unlike many supply-chain incidents that exploit a misconfigured pipeline or a stolen token, the XZ backdoor was a long game. The attacker did not need to break into a build system from the outside. They worked their way into the project's social fabric first, then used that trust to shape the code, the tests, and eventually the release process itself.

The timeline below shows how that unfolded, from a new GitHub identity in 2021 to public disclosure in March 2024.

What stands out is the pacing. This was not a smash-and-grab. It was maintainer fatigue, community pressure, incremental access, and technical preparation spread across multiple years. By the time malicious tarballs appeared, the attacker had already shaped parts of the environment that would help the backdoor survive scrutiny.

How the backdoor was obfuscated

The xz backdoor was not dropped in as an obvious malicious file sitting in the repository for everyone to review. It was designed to appear only at the right moment, in the right build, on the right kind of system. That is why it remained hidden for so long.

The obfuscation unfolded in five linked stages:

Together, these steps created a backdoor that was difficult to spot in normal source review, difficult to trigger accidentally, and difficult to detect with standard tooling unless you were already looking in exactly the right place.

The malicious code was not in the Git tree everyone reviewed. It was in the release artifact everyone trusted.

Why this incident still matters

The XZ compromise is often remembered as a near miss, and it was. The backdoor was caught before it reached most stable production environments. But “near miss” is not the same as “no lesson.”

The incident showed how a patient attacker can combine maintainer social engineering, trusted release processes, and build-time stealth to target the software supply chain. It also showed that open-source trust models, with small maintainer teams, volunteer burnout, and community pressure, can become part of the attack surface when nobody is paying attention.

What teams should take from this

Most organisations will never maintain a compression library. That is fine. The lesson is broader: critical open-source components deserve more than passive trust, and the path from contributor to maintainer deserves more scrutiny than we usually give it.

Practical responses include verifying release tarballs against source, monitoring maintainer changes in critical dependencies, supporting maintainer sustainability before burnout creates gaps, and treating unusual runtime behaviour in core infrastructure as a security signal rather than a performance nuisance.

XZ was caught because someone noticed SSH behaving oddly. That is both reassuring and uncomfortable. Reassuring because the system worked once. Uncomfortable because the next attempt may be quieter, better funded, and better hidden.