This Is The Most Insane "Hack" In History. Nobody Saw This Coming.
In this article
> **Bottom line:** In March 2024, a Microsoft engineer named Andres Freund almost didn't notice a 500-millisecond SSH login delay — and that near-miss is the only reason a state-level backdoor didn't land inside nearly every Linux server on Earth.
The attacker, known only as "Jia Tan," spent roughly two to three years building trust inside the xz-utils project before slipping malicious code into versions 5.6.0 and 5.6.1 of liblzma, a compression library buried deep in the Linux dependency chain.
The payload targeted OpenSSH and could have granted remote code execution on millions of machines, tracked as CVE-2024-3094.
It was caught by accident, not by process — and that's the part the open-source community doesn't want to talk about.
Stop telling me open source is secure because "many eyes make all bugs shallow." I'm serious.
That line — Linus's Law, quoted in every conference talk and every corporate security policy for twenty-five years — nearly got the entire internet backdoored in 2024, and it was saved by one engineer's irritation over a slow SSH login, not by the "many eyes" doing their job.
I've spent over a decade around infrastructure teams who treat "it's open source, so it's been reviewed" as a compliance checkbox.
After digging into exactly how close the xz-utils attack came to succeeding, I don't think that checkbox should exist anymore.
The Sacred Cow: "Open Source Means Someone's Watching"
I get why people believe it. The pitch is seductive: unlike closed-source software, where you're trusting a vendor's word, open source lets anyone read the code.
Thousands of eyeballs, endless scrutiny, bugs caught before they ship.
It's the founding myth of the entire free software movement, and for a lot of small, popular projects, it's held up reasonably well.
Five years ago, that story felt basically true.
Critical vulnerabilities in projects like OpenSSL or the Linux kernel *did* get caught by outside researchers, security firms threw money at fuzzing infrastructure, and high-profile projects had real, funded maintainers.
Here's what changed: the software supply chain quietly became enormous and nobody scaled the review process to match it.
A modern Linux distribution depends on tens of thousands of packages, many maintained by a single unpaid volunteer in their spare time.
**xz-utils — a compression tool used by practically every Linux system on the planet — was maintained by one person, Lasse Collin, who had been publicly struggling with burnout and mental health for years.** That's not a hypothetical weak point.
That's the actual, documented state of a library sitting in your dependency tree right now.
The Evidence: How Close We Actually Came
A Two-Year Con, Not a Hack
"Jia Tan" first showed up on the xz-utils mailing list in 2021, submitting small, legitimate patches. Over roughly two years, the account built a reputation as a helpful, competent contributor.
Around the same time, other accounts — now widely believed to be sockpuppets working with Jia Tan — started pressuring Collin in mailing list threads, complaining that the project was stagnant and that he wasn't merging patches fast enough.
Collin, exhausted and dealing with real personal issues, eventually added Jia Tan as a co-maintainer with commit access. **This wasn't a technical exploit.
It was a multi-year social engineering campaign against a single tired human being**, and it worked exactly as designed.
The Backdoor Itself Was a Masterpiece of Hiding
Once Jia Tan had commit access, the actual malicious code didn't show up as an obvious backdoor in a `.c` file where a reviewer might spot it.
It was smuggled in through binary test files disguised as corrupted compression test data, activated by a chain of obfuscated build-script modifications that only triggered during the creation of official release tarballs — not in the public GitHub source tree itself.
That distinction matters enormously. Anyone auditing the GitHub repo would have seen nothing wrong.
The backdoor only assembled itself when Debian, Fedora, and other distros built packages from the official release archive, specifically when linked against OpenSSH via a chain involving systemd's dependency on liblzma.
The final payload was designed to intercept SSH authentication and allow a remote attacker holding a specific private key to execute arbitrary code — an authentication bypass hiding inside a compression library nobody thinks about.
It Was Caught by Accident
Here's the part that should scare you more than the backdoor itself. Andres Freund wasn't doing a security audit.
He was a PostgreSQL contributor troubleshooting why SSH logins on a Debian testing system felt sluggish and were eating unusual amounts of CPU in Valgrind.
He chased a 500-millisecond delay out of pure engineering annoyance, traced it to liblzma, and pulled a thread that unraveled one of the most sophisticated supply chain attacks security researchers have ever documented.
**If Freund hadn't happened to be running that specific testing distribution, with that specific profiling tool, irritated by that specific half-second lag, the backdoored versions were on track to reach stable releases of Debian and Fedora within weeks.** Millions of production servers.
Nobody reviewing it caught it. Luck caught it.
The Real Problem Nobody Talks About
The real problem isn't that one malicious actor infiltrated one project.
It's that the entire global software supply chain runs on the unpaid, unsupervised labor of volunteers maintaining infrastructure that Fortune 500 companies and governments depend on — and we've built no process that scales to catch what happened here.
Every "many eyes" argument assumes those eyes are funded, rested, and looking at the right files.
In xz-utils's case, the eyes belonged to one burned-out person who was targeted specifically *because* he was burned out. The attacker didn't beat the code review process.
**The attacker beat the fact that there was barely a process at all.**
This is the uncomfortable math: the 2023 Linux Foundation Census found a huge share of critical open-source infrastructure is maintained by fewer than five people, and a meaningful chunk by exactly one.
We've centralized the entire internet's trust model on top of a labor structure that looks nothing like the "community of engaged reviewers" story we tell ourselves.
The xz-utils attack wasn't an aberration in that system. It was the system working exactly the way its incentives point.
What You Should Do Instead
Stop treating "open source" as a security property on its own. It isn't one — it's a *precondition* for security review, not the review itself. Here's what actually moves the needle:
- **Pin and audit your dependency tree, not just your direct dependencies.** liblzma wasn't in anyone's direct `package.json` or `requirements.txt` — it was three or four layers deep.
Tools like `deps.dev`, Sigstore, and SBOM generators exist specifically to surface that hidden chain.
- **Fund the maintainers you depend on.** If your company ships software that touches xz, curl, OpenSSL, or similar critical infrastructure, and you're not contributing money or engineering time back, you are freeriding on exactly the kind of exhausted volunteer who got targeted here.
- **Treat sudden "helpful" contributors to critical infra with suspicion, not gratitude.** A pattern of new accounts pressuring a maintainer to hand over access faster is now a known attack signature.
Watch for it in your own upstream projects.
- **Reproducible builds matter more than code review.** The whole point of this attack was that the malicious code wasn't visible in the source tree — only in the built artifact.
Distros that build reproducibly and diff against independent builds have a real shot at catching this class of attack; ones that trust a maintainer's tarball do not.
The Uncomfortable Truth
We didn't dodge a bullet because open source works the way we tell ourselves it works.
We dodged it because one annoyed engineer happened to be running the right tool at the right moment, and a nation-state-caliber operation made one small performance mistake after two years of near-perfect execution.
Next time someone tells you a piece of software is safe because "it's open source, people would notice" — ask them who, specifically, is looking, whether that person is getting paid, and whether they've slept this week.
What's the one dependency in your stack you've never once actually opened and read? Let's talk about it in the comments.
