Most people know Linux exists but don't really think about how deeply embedded it is. Android runs on a Linux kernel, the majority of web servers run Linux, even every one of the top 500 supercomputers in the world runs Linux. Hospitals, banks, government systems, nuclear submarines, etc. It is the invisible infrastructure of the modern internet.
Because it's open source, anyone can read the code, submit changes, find bugs. The idea has always been that this openness is a security feature, as with enough people looking at the code, vulnerabilities get caught quickly. This is called the Linus's Law, "given enough eyeballs, all bugs are shallow."
The problem is that Linux as most people use it is not one project. It's a massive dependency graph of thousands of smaller projects, each doing something specific. Compression, networking, cryptography, whatever. A lot of these got started by one developer who had a problem and built a tool to fix it. Then another project depends on it, then another, and before long you have millions of machines relying on something that's maintained by a single person in their spare time, for free. There's a famous xkcd comic about this that pretty much nails it.
And surprise! That's the actual attack surface here. Yes, the risk does not lie simply in the code base itself, but it was the people maintaining it.
XZ Utils is a lossless data compression tool that Lasse Collin, a Finnish developer, has been working on since 2005. If you've ever wondered what format Linux packages, kernel images, and firmware updates get shipped in, a lot of it is .xz. The algorithm it uses under the hood is LZMA, developed by Igor Pavlov in the late 90s, which combines a very large sliding window dictionary lookup (so it can reference patterns from much earlier in the file) with a Markov-chain-based probability model for encoding. The result is compression that often beats zip by around 30%. When you're shipping the same files to millions of machines, that adds up.
Lasse maintained XZ alone, unpaid, for nearly twenty years. And over time, the community pressure got heavy. There are mailing list threads where strangers are openly telling him he's "choking the repo," that he's failing the project, that things will go nowhere until there's a new maintainer. He's trying to explain that this is a free hobby project and he's dealing with long-term mental health issues. The community, however, did not really engage with that.
Right around when Lasse was at his most burnt out, a developer called Jia Tan appeared. Responsive, competent, genuinely helpful. He submitted good patches, fixed real bugs, handled some of the day-to-day maintenance load that Lasse had been drowning in. Over time, Lasse gave him co-maintainer status. It took about two years.
But the weird thing is when looking back at those mailing list threads where people were pressuring Lasse, the accounts doing the pressuring have almost no online footprint. Free email addresses, nothing outside XZ discussions. Almost certainly sockpuppets, fake identities manufactured to create a crisis so that Lasse would welcome outside help. The whole thing was a years-long social engineering campaign targeting one volunteer developer to get control of one specific compression library.
Why that library? Because XZ had ended up in the dependency chain of OpenSSH.
SSH is how you log into a remote Linux machine. Every time a developer SSHes into a server, every automated deployment pipeline, every monitoring system checking on remote hosts, they're all going through SSH. OpenSSH is the implementation that ships on almost every Linux system. It handles authentication using public key cryptography, the RSA-based system where your private key never leaves your machine and the server just needs your public key to verify who you are.
OpenSSH is one of the most scrutinized pieces of software in existence. Getting a backdoor into it directly is essentially impossible at this point. But OpenSSH doesn't exist in a vacuum. It links against shared libraries, and one of those libraries, through a chain of dependencies, pulls in XZ.
So Jia's plan was to compromise XZ in a way that would eventually compromise OpenSSH without ever touching OpenSSH's code.
This is where it gets technically interesting.
The first step was to hide the payload. Jia didn't put any malicious code in XZ's actual source. He hid it inside binary test files, the kind of compressed blobs that compression software ships to verify that encode and decode are working correctly. Nobody audits those, they're treated as opaque data. The payload was sitting in there looking like test fixtures.