The XZ Utils backdoor: how trust in open source was abused.
A small performance oddity exposed one of the most notable supply-chain attacks in the Linux world.
XZ Utils is a widely used tool for compressing and decompressing files. Its liblzma library is also a building block used by many Linux programs. In 2024, a backdoor was planted in some releases of the project. What made the incident notable was that the attack exploited trust in how software is developed and distributed, not just a code flaw.
What happened?
Malicious code was found in XZ Utils versions 5.6.0 and 5.6.1. It was concealed in a way that was not immediately obvious in the source repository and took effect while release tarballs were being built. The target was not every Linux computer: the risk applied to certain packages and systems under specific conditions. So it would be inaccurate to say “everyone running Linux was affected.”
The backdoor was designed to interfere with SSH server authentication when the right conditions were met. SSH is a common way to connect securely to another computer. The issue, then, was not only the security of a compression tool; the indirect connections that tool had with other systems mattered too.
How was it found?
In March 2024, Microsoft engineer Andres Freund noticed that SSH connections were unexpectedly slow on some systems and that tests were producing unusual errors. Following that small performance difference led him to connect the problem to newer XZ Utils releases. Distributions were alerted, suspicious versions were pulled back and a wider investigation began.
What stays with me is that a major security problem can emerge not from a dramatic alarm, but from an attentive engineer asking, “Why is this process a little slower than usual?”
How was trust exploited?
This was not a single, obvious change added all at once. An account that had contributed to the XZ project over time gained responsibility; later, malicious code made its way from the release-preparation process into distributed packages. Rather than repeating unverified guesses about someone’s identity, it is better to focus on the verified technical process: trust, maintainer workload and the packaging chain all became part of the attack.
It is a major advantage that anyone can inspect open-source code. But open source does not mean every release is automatically safe. A distributed source package can differ from what is visible in the repository, and a library can also end up connected to another critical component in an unexpected way.
What I take from this
When working with systems, I think it is important to look beyond dependency names and ask how they are produced and which components they pass through. A single person carrying the maintenance burden for a long time can become a security risk for a project. A second set of eyes, reproducible builds, signed releases and independent checks by distributions all matter for that reason.
The XZ incident was not a failure of open source; it was a serious warning about how interconnected the open-source ecosystem is. The problem was caught early and distributions responded quickly, preventing a much wider impact. Even so, after this incident, “the code is open, so it must be fine” no longer feels like enough to me.
The releases at the center of the incident were XZ Utils 5.6.0 and 5.6.1. The impact depended on the Linux distribution and packaging method. To understand a system’s status, rely on your distribution’s security notice and update guidance.
Watch the video
For a closer look at the background, here’s Veritasium’s video with Turkish dubbing:
Watch the Turkish-dubbed video on YouTube ↗