The xz backdoor starts here, inside a file nobody reads.
# stage 1: "uncorrupt" a test file, then decompress it into a script
tr "\t \-_" " \t_\-" < tests/files/bad-3-corrupt_lzma2.xz | xz -dcAndres Freund noticed his SSH logins burned ~500ms of CPU they should not, and Valgrind threw weird errors in liblzma. He profiled half a second. That is the kind of Postgres developer he is. What he found was a backdoor in xz/liblzma wired into sshd. It had shipped to Debian sid, Fedora 40/41 beta and openSUSE Tumbleweed, weeks from stable releases everywhere.
The payload is world-class tradecraft. It is still the boring half of the story.
The payload, briefly, because it is gorgeous
The git repository was clean. The release tarballs were not. A modified build-to-host.m4 existed only in the tarball's generated autotools output, the part of a release nobody diffs. From there comes the tr line above. gynvael's analysis reconstructs the rest.
Stage 2 carves byte ranges out of a second "test" file with head and tail. It decrypts them with an RC4 variant implemented in AWK, then links the object file into liblzma. At runtime the backdoor abuses glibc IFUNC resolvers, and they run during dynamic linking before main. The hook lands on symbol resolution and intercepts RSA_public_decrypt inside sshd.
Why does sshd load a compression library at all? It does not, upstream. Distros patch OpenSSH to link libsystemd for sd_notify, and libsystemd pulls liblzma. The attack rode a distro patch, not OpenSSH.
The trigger is elegant. An attacker presents an SSH certificate. Its CA field smuggles a ChaCha20-encrypted command. The backdoor verifies it against a hardcoded ed448 public key, then hands it to system(). Pre-auth RCE, cryptographically locked to the author, invisible in logs. xzbot demonstrates it end to end with a known key. A February commit "accidentally" broke the configure test for Landlock sandboxing with a stray syntax error. Every accident pointed the same direction.
The org chart was the vulnerability
Rewind three years, with Russ Cox's timeline and the community FAQ open. Lasse Collin maintains xz alone, unpaid, for over a decade. In 2021 a contributor appears: Jia Tan. Helpful, competent, tireless. Around the same time, accounts that exist nowhere else start working the mailing list. Jigar Kumar, June 2022: "Progress will not happen until there is new maintainer." Collin, one day later: "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues." The good cop commits. The bad cops squeeze. By the end of 2022 Jia Tan has the keys. Added to the Tukaani org in October. Co-maintainer in the README by November. Direct releases after that.
Then two more years of legitimate work. Trust compounds like interest. The withdrawal came in xz 5.6.0, hidden where code review is structurally blind: binary test fixtures and generated build scripts. bad-3-corrupt_lzma2.xz is a corrupt-input fixture. Nobody reviews one. The attacker had engineered the review surface away.
Strip the tradecraft. Look at what the attacker hit:
- A single maintainer with no succession plan and no institution behind him.
- Burnout as the entry point. The pressure campaign was not hacking. It was HR.
- A trust model where years of good commits equal root on the planet.
No CVE patches that. The attacker was likely salaried and patient, and understood what the industry still refuses. The cheapest zero-day in the supply chain is a tired volunteer. xkcd drew the stick that holds everything up years ago. Someone finally kicked it, professionally.
I built RFM in 2020 around this failure mode. I thought abandonment was the risk. I undershot. The worse outcome is that someone answers the maintainer's call for help, and it is not who you hope.
The checklist writes itself, and none of it is technical. Know which single-maintainer packages sit in your money path. Fund them, staff them, or vendor them. When a maintainer says he is burning out, that is a security advisory.