Skip to content
article

the XZ backdoor was not a hack. it was a hostile takeover of a tired volunteer.

what March 2024 should have taught us about the social layer of open source, and mostly did not

Karl Lindqvist@kernel_karl

July 16, 2026 · 2 min read

everyone remembers the XZ backdoor (CVE-2024-3094, March 2024) as "the thing that almost backdoored SSH on every Linux box". that part is true and it was caught by luck, a Microsoft engineer noticing a half second of latency. but if you only remember the clever technical part you learned the wrong lesson.

here is the short technical shape of it, and this Seytonic video does the timeline well if you want the full story:

what actually happened

xz is a compression library, maintained for years largely by one person, Lasse. a new contributor appeared, "Jia Tan", helpful, patient, technically competent. over many months they made real contributions, built trust, and were gradually handed more responsibility. meanwhile sockpuppet accounts pressured the exhausted original maintainer in the issues, complaining the project was slow, suggesting it needed a new maintainer. a textbook pressure campaign on a burned out volunteer. once "Jia Tan" had commit and release authority, they slipped an obfuscated backdoor into the release tarballs (not even the git tree, the generated build files, where nobody looks).

the lesson nobody wants

this was not a software vulnerability you can scan for. it was a social engineering attack against the human maintenance model, and that model is: one tired person, no funding, and a pile of strangers who feel entitled to their time. the attacker did not break the code. they broke the person, or rather they exploited the fact that the person was already broken by exactly the dynamic I rant about every week.

  • every "is this still maintained??" and "why is this so slow" issue is, at scale, the attack surface. the pressure that softened Lasse up was indistinguishable from normal open source entitlement.
  • handing over maintainership is a security event, not an HR nicety. we have no good process for it because we pretend maintainers are infinite.
  • the fix is not "more scanning". it is funding and staffing critical infrastructure so a single exhausted human is not the thing standing between you and a backdoor in your SSH.

I have been handed "helpful" contributors on skerry and felt the pull of "finally, someone to share the load". it is a real feeling and it is exactly the lever that was pulled here. we were lucky once. luck is not a maintenance strategy. fund the maintainers, not the scanners.

Written by

Karl Lindqvist

Maintainer of skerry, the C JSON parser your company vendors and never thanks. 14 years, 2 co-maintainers, 0 budget. Gothenburg. Read CONTRIBUTING.md before you open an issue.

Get the best of #hack_the_planet weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.

Comments

7

Sign in to join the conversation.

Sign in to comment
Nadia Benali@nullbyte_nadia#1 in Hack The Planet
the "you learned the wrong lesson if you only remember the clever part" framing is exactly right. everyone shared the five lines of obfuscated code. almost nobody shared the months of sockpuppets wearing a maintainer down. the social attack was the attack.
3 net votes
Arash Karimi@arash_403#7 in Hack The Planet
The detail that it was in the release tarball and not the git tree is the one I keep repeating to people. We all audit the repo. Almost nobody audits what the build actually ships. It was found by a latency measurement, by accident. That should frighten everyone.
4 net votes
Lena Hoffmann@arch_btw_lena1 rep in Hack The Planet
i think about this every time i see a "this project looks abandoned, can i take over maintainership?" comment now. sometimes that is a kind stranger. once, that we know of, it was this. handing over keys is a security event, you are so right.
3 net votes
Frank Ostrowski@frank_cpp981 rep in Hack The Planet
And it was a compression library written in C, maintained properly for years, until the attack was on the Human not the Code. No language feature stops a maintainer being socially engineered into handing over the keys. Memory safety would not have touched this one. Regards.
4 net votes
Ondřej Hrubý@rewrite_it_in_rust1 rep in Hack The Planet
true that rust would not stop the social part but a reproducible build and no autotools tarball nonsense would have made hiding it much harder, the build system being a dark forest is half the story
1 net votes
Karl Lindqvist@kernel_karl#2 in Hack The Planet
That part I actually agree with, Ondřej. The generated build files being where nobody looks is a real, fixable problem. Reproducible builds would help. That is a concrete thing, unlike "rewrite everything". Write that up, I would read it.
6 net votes
Graham Whitfield@greybeard_graham1 rep in Hack The Planet
The bus factor strikes again, except someone pushed the bus. I have watched organisations run for a decade on one person who could not take a holiday. We never treated that as a risk. The attackers did. Cheers, G.
6 net votes