In early 2024 the open-source world had its closest call in memory: a carefully hidden backdoor in a core Linux compression library, planted not by an outside hacker but by a maintainer everyone trusted - and discovered almost entirely by accident. Here is the story of the XZ backdoor, and why it matters even if you never touch code.
Quick answer
The XZ backdoor (CVE-2024-3094) was malicious code hidden in versions 5.6.0 and 5.6.1 of the xz/liblzma compression library in 2024, planted by a trusted maintainer, that could let an attacker bypass SSH authentication on affected Linux systems. It was caught by chance before it reached most stable distributions.
What is XZ, and why does it matter?
XZ Utils is a small, unglamorous compression library (liblzma) used quietly by countless programs across virtually every Linux distribution. It is exactly the kind of foundational, taken-for-granted component nobody thinks about - which is precisely what made it the perfect place to hide something.
The long con
This was not a smash-and-grab. Over roughly two to three years, an account known as "Jia Tan" became a productive, helpful contributor to the XZ project - fixing bugs, doing real work, slowly earning the trust of the overworked original maintainer until they were handed co-maintainer privileges. It was patient social engineering aimed at the human side of open source, not the code.
The attacker did not break in. They were invited in, after years of being a model open-source citizen.
The backdoor itself
In early 2024, malicious code was hidden in release versions 5.6.0 and 5.6.1 - disguised inside test files and build scripts so it did not show up in the normal source. Once compiled, it tampered with the system's SSH process: a machine running the poisoned library could be silently unlocked by anyone holding the attacker's secret key, giving them remote access as root. A near-invisible master key to a huge share of the world's servers.
Caught by half a second
The discovery is the wildest part. A Microsoft engineer, Andres Freund, noticed that SSH logins on a test system were about half a second slower than expected and used a little more CPU than they should. Most people would have shrugged. He chased the tiny anomaly down and uncovered the entire backdoor - days before the poisoned versions would have rolled into major stable, long-term-support distributions.
How bad could it have been?
Catastrophic. Had it reached the mainstream stable releases, a significant fraction of the internet's Linux servers could have been silently backdoored at the SSH level - the single most sensitive door on a server. It was caught in the narrow window between the malicious release and wide adoption, by luck and one engineer's curiosity.
Timeline: how it unfolded
- ~2021-2023 - "Jia Tan" builds trust with genuine contributions to the XZ project.
- Late 2023 - early 2024 - gains co-maintainer access and begins introducing the backdoor across several small, hard-to-spot commits.
- February-March 2024 - the poisoned code ships in versions 5.6.0 and 5.6.1, and starts filtering into bleeding-edge distribution packages.
- 29 March 2024 - Andres Freund reports the anomaly publicly; the backdoor is confirmed and versions are pulled within hours.
The uncomfortable lessons
- Trust is a target. The attack exploited human trust and maintainer burnout, not a coding mistake.
- Critical infrastructure is fragile. Vast swathes of the internet rest on tiny projects run by a handful of unpaid volunteers.
- Supply-chain risk is real. You can do everything right and still inherit a backdoor from a dependency you did not know you had.
- Open source still won. It was the openness of the code and build process that let an outsider catch it at all.
What it means for you
You cannot personally audit every library on your server - but you can limit the blast radius. Stay on stable, well-maintained distributions (the fast-moving releases were the ones targeted; the conservative stable ones were saved by their slowness), keep systems patched, and reduce what is exposed. It also belongs on the list of famous Linux vulnerabilities, and connects to the wider shifts in Linux and OS security, including the very CentOS-to-Rocky/Alma stability question this incident put back in the spotlight.