The xz backdoor: the attack that waited two years

A long game

xz was maintained, for most of its life, by one volunteer. The attack began with help: small, useful patches. Then, as Jia Tan's patches waited for review, other accounts appeared on the mailing list complaining that the project moved too slowly and should take on a new maintainer.

How it hid

• Not in the code anyone reads. The payload sat in two compressed “test” files. A modified build script — present only in the release tarballs, not in git — extracted it during the build.
• Only where it mattered. It injected itself only into x86-64 Linux builds made with gcc as Debian or RPM packages, and only switched on inside /usr/sbin/sshd.
• Through a side door. OpenSSH does not use xz. But several distributions patch sshd to talk to systemd, and systemd loads liblzma — so the library ended up inside the SSH server anyway.
• Before the login. The backdoor redirected RSA_public_decrypt, a function sshd calls while checking a key — before authentication completes. Whoever held the attackers' Ed448 private key could run commands on the machine.

Caught by half a second

Freund was chasing a performance regression on Debian's development branch when sshd started using surprisingly much CPU and valgrind began reporting errors. The difference was small enough to ignore:

From the first harmless patch to public disclosure

2 yr 5 moRuss Cox, xz timeline

CVSS score of CVE-2024-3094 — the maximum

10.0Red Hat / NVD

Release versions that carried the backdoor: 5.6.0 and 5.6.1

2Andres Freund, oss-security

Our reading

Analysis — Altumptic's interpretation of the reporting above.

• The attack surface was a person. No exploit was needed to get commit rights — only patience, useful work and a tired maintainer under public pressure.
• What is reviewed is not what is shipped. Everyone reads the repository; almost no one diffs a release tarball against it. That gap was the whole hiding place.
• Distribution patches create invisible dependencies. The path from sshd to liblzma existed only because of a convenience patch downstream.
• Performance is a security signal. The detection was luck plus curiosity. A baseline of how long logins take, and which libraries sshd loads, turns that luck into a process.

For a lab whose monitoring tool, ALT-02 LemonSees, treats the SSH session as the agent, this case is close to home: that session is only as trustworthy as the sshd binary and every library it loads.

What to check on your servers

1. Confirm no host, image or container runs xz 5.6.0 or 5.6.1 — old Debian images on Docker Hub still contained it in 2025.
2. Record which libraries sshd loads (ldd /usr/sbin/sshd) and alert when that list or those files change.
3. Keep production on stable distribution channels; the exposed systems ran testing, unstable or rolling releases.
4. Treat unexplained CPU or latency in sshd as a security event, not just a performance one.
5. Where you build from source, build from the repository, or compare release tarballs against it before trusting them.