On March 29, 2024, Microsoft engineer Andres Freund posted a terse message to oss-security: liblzma, the compression library shipped with xz-utils 5.6.0 and 5.6.1, contained a backdoor that hooked into OpenSSH's authentication path on affected systemd-enabled distributions. The finding was the product of an investigator noticing a 500 millisecond delay during SSH logins and half a watt of extra CPU load, not a formal audit. Red Hat issued CVE-2024-3094 with a CVSS of 10.0 the same day. The implant had been merged by a maintainer named "Jia Tan" who spent roughly two years building trust in the project before landing the payload. It reached Fedora 40 beta, Debian sid, openSUSE Tumbleweed, Kali rolling, and Arch. Production LTS distributions were spared only by timing. This post walks through how the implant was staged, how it hooked sshd without ever appearing in source, and what the incident reveals about maintainer trust as a supply chain attack surface.
Who is Jia Tan and how did the backdoor get merged?
The backdoor was merged by an account named Jia Tan (JiaT75) who had contributed to xz-utils since late 2021 and became the de facto co-maintainer alongside Lasse Collin by 2023. The handle corresponded to a sockpuppet campaign: accounts like "Jigar Kumar" and "Dennis Ens" pressured Collin on the mailing list throughout 2022 to hand off more responsibility, citing burnout. Over 18 months JiaT75 landed legitimate fixes, became a Google OSS-Fuzz contact, and gained commit rights. The malicious payload arrived across a sequence of commits in February and March 2024, split between the Git repository and the release tarball so that neither view alone looked suspicious. The Git tree contained harmless-looking test fixtures; the tarball added a build-time script that stitched them together.
How was the payload delivered through the build system?
The payload was hidden in two compressed "test files" — bad-3-corrupt_lzma2.xz and good-large_compressed.lzma — that contained the real implant. During ./configure, a modified build-to-host.m4 macro invoked a hidden .m4 script that pulled bytes from those test files, deobfuscated them with a chained sequence of tr and head, and injected the result into the build as an object file linked into liblzma. Crucially, the malicious logic was never in version-controlled source that you would see with git log. Anyone diffing the Git tree against upstream saw only innocuous test data. Only the tarball produced by make dist contained the wired-up build-to-host.m4. This is the textbook argument for reproducible builds from VCS, not from tarballs.
How did the implant hook sshd without OpenSSH depending on xz?
The implant abused a transitive linkage created by systemd: OpenSSH on Debian and Fedora links against libsystemd for notification sockets, and libsystemd in turn links against liblzma for journal compression. Once loaded into the sshd address space, the implant used GNU IFUNC resolvers to redirect calls to RSA_public_decrypt inside OpenSSL to its own function. When sshd authenticated a public key, the hooked resolver inspected the certificate, extracted a payload from specific fields, and — if the payload was signed with an attacker-controlled ED448 key — executed commands via system() before authentication completed. The result was a pre-auth remote code execution primitive that only triggered for the attacker, invisible to anyone without the private key.
Which distributions were exposed and which dodged the bullet?
Rolling and beta distributions shipped the backdoored 5.6.0 or 5.6.1, while enterprise LTS releases did not. Fedora 40 beta and Fedora Rawhide, Debian testing and unstable, openSUSE Tumbleweed and MicroOS, Kali Linux (between March 26 and 29), and Arch Linux all carried the bad versions. Ubuntu 24.04 beta briefly included 5.6.1 before being rolled back pre-release. Red Hat Enterprise Linux, Debian stable (bookworm), Ubuntu 22.04 and 20.04, and Amazon Linux 2 were unaffected because they ship older xz. The timing was luck: Freund found it weeks before Fedora 40 and Ubuntu 24.04 were scheduled to go GA, which would have meant tens of millions of production installs.
What does this tell us about detection beyond signatures?
Signature-based detection would have missed this entirely — the payload did not match any prior malware family, and its code never lived in source. What caught it was behavioral: a half-second latency regression and anomalous CPU usage during failed SSH logins. That matches a broader pattern from 2023 and 2024: event-stream, ua-parser-js, the 3CX supply chain compromise, and now xz-utils were all initially detected by runtime anomalies rather than static scanning. Defenders need SBOM provenance (who built this, from which commit, on which runner), reproducible builds (does the tarball match the Git tree), and behavioral telemetry on critical binaries. None of those individually would have stopped Jia Tan, but together they make the implant much louder.
What should SREs and platform teams do right now?
Audit every system running a rolling release, confirm the installed xz version with xz --version, and roll back to 5.4.6 or pin to distro-approved versions. Run the detection script Freund published that checks for the IFUNC hook symbol in loaded sshd processes. Rotate any SSH host keys on systems that ran 5.6.0 or 5.6.1 with network exposure — you cannot prove the key was not exfiltrated. Longer term, inventory every dependency that ends up in the address space of network-facing daemons; liblzma inside sshd surprised a lot of engineers who would have sworn SSH did not depend on xz.
# Quick triage on a suspected host
xz --version | head -1
# If 5.6.0 or 5.6.1, assume compromise and rotate keys
ldd $(which sshd) | grep -E 'liblzma|libsystemd'
How Safeguard Helps
Safeguard flags xz-utils 5.6.0 and 5.6.1 as malicious at ingest and traces the transitive path from sshd to liblzma through libsystemd using reachability analysis, so you see not just that the package is present but that it reaches a network-facing daemon. Griffin AI correlates the anomalous maintainer change pattern — a newly trusted committer landing obfuscated binary test fixtures — against similar historical takeover attempts, surfacing review recommendations before a release ships. Every SBOM ingested includes provenance attestations, so tarball-only payloads like build-to-host.m4 trigger a mismatch between the VCS and the distributed artifact. Policy gates block builds when any component matches the xz advisory or shows unresolved provenance, and TPRM assessments flag vendors still shipping the affected range. Together these controls catch both the specific xz payload and the maintainer-trust pattern behind it.