On 29 March 2024, a Microsoft engineer named Andres Freund posted to the oss-security list about an odd observation: SSH logins on his Debian testing machine were taking about 500 milliseconds longer than they should, and sshd was consuming unusual CPU.
He traced it to a backdoor in liblzma, part of XZ Utils. Had it shipped, it would have provided remote code execution in sshd on a large fraction of Linux systems running systemd.
What the backdoor did
The payload targeted the systemd notification path in sshd. By hooking a function called during the authentication flow, it was positioned to inspect authentication traffic, and — with a correctly signed command — execute it before authentication completed.
The attacker held the private key. Nobody else could use it.
How it got in
The mechanism is the part worth internalising, because it required no traditional vulnerability at all.
1. Two years of community building. An account using the name “Jia Tan” began contributing to XZ Utils in late 2021, gradually taking on maintenance responsibilities for a project whose original maintainer was burning out.
2. Social pressure on the maintainer. Multiple sockpuppet accounts pushed the original maintainer to hand over more control, including complaints that releases were too slow. This is a real pattern in open source, and it worked.
3. Injection during the build. The malicious code was not in the source file you read. It was hidden in m4/build-to-host.m4 — a build script — alongside an obfuscated test file containing the payload, which was decoded at build time. A grep of the C sources finds nothing.
4. Plausible deniability in the released tarball. The malicious build script existed in the release tarballs but not in the git repository. Anyone auditing the repo would see clean code; anyone building from the tarball — which is what distributions do — got the backdoor.
5. Targeted activation. The result only interfered with sshd when built under specific conditions and running with systemd. It wasn’t a broad backdoor; it was aimed at one thing.
Why it was caught
Almost by accident. The tell was a performance measurement — a half-second delay in SSH authentication — noticed by someone who knew what a login normally felt like and looked at the process tree instead of shrugging.
If the payload had been slightly more careful about CPU usage, it would plausibly have shipped in Debian unstable and Fedora rawhide and then migrated downstream over the following months.
What actually works against this
The uncomfortable conclusion is that most controls did not help. There was no CVE to patch, no signature to match, and no obvious behaviour to alert on. What did help:
- Reproducible builds. If distributions could rebuild from source and compare binaries, a build-time injection is detectable. This is the strongest technical control in the list, and it is not widely deployed.
- Diffing release tarballs against the git tree. The discrepancy between the tarball and the repository was a concrete, checkable fact.
- Multiple maintainers with independent infrastructure. The attack depended on concentrating trust in one person.
- Boring anomaly detection on performance. CPU and latency baselines on core daemons would have flagged it sooner.
What I took away
Three things:
- “It’s open source, someone would notice” is not a security control. This was open source, in a critical path, and it survived two years and multiple releases. The review capacity does not exist at the scale people assume.
- Build scripts are part of the attack surface. Reviewing only the C source is reviewing the wrong artefact.
- Maintainer burnout is a security issue. The social engineering here exploited a resource problem — too much work for too few people — and the same approach will be tried again, on other projects, with better tradecraft.
Australia’s government and several others responded with coordinated disclosure. Debian and Fedora reverted the affected versions. The near-miss framing is accurate: the bug was real, the release window was narrow, and the detection was luck as much as skill.