The XZ Utils backdoor: a three-year social engineering campaign

I have strong, well-sourced material and four verified images. Writing the post now.

The 500-millisecond anomaly

In late March 2024, a Microsoft engineer named Andres Freund was doing something unglamorous: benchmarking a database. He was running micro-benchmarks on PostgreSQL on a test machine running Debian's "sid" branch, the distribution's perpetually unstable development version. Something was off. Logins over SSH, the encrypted protocol nearly every server administrator on Earth uses to reach remote machines, were burning noticeably more processor time than they should, and his monitoring tools were throwing odd errors from a library called liblzma. The delay was tiny. A failed SSH login that used to take about 0.3 seconds was now taking roughly 0.8 seconds, a difference of half a second that almost no one would ever notice or bother to chase. Freund chased it. In his now-famous disclosure to the oss-security mailing list on 29 March 2024, he laid out what he had found after days of profiling with tools like perf and gdb: someone had planted a backdoor in XZ Utils, a compression library so mundane and so ubiquitous that it ships, in one form or another, on essentially every Linux system in the world.

What Freund had stumbled into, catalogued as CVE-2024-3094, was not an ordinary bug. It was the payload of a patient, roughly three-year social engineering operation aimed at one of the least-defended targets in modern computing: the trust between volunteer maintainers of open-source software. Had Freund been slightly less curious, or had the attackers moved a few weeks faster, the backdoor would have shipped in the stable releases of major Linux distributions and, from there, onto a large fraction of the internet's servers.

What XZ Utils actually is, and why it matters

XZ Utils is a set of command-line tools and a software library (liblzma) for data compression, the same basic job as a ZIP file. It implements the LZMA algorithm and produces .xz files. This is deeply unsexy infrastructure. It compresses kernel images, package archives, and log files. It is a dependency of a dependency of a dependency across the Linux world, the kind of code that runs billions of times a day while almost no one thinks about it. The crucial detail is a chain of linkages. On many Linux distributions, the SSH server daemon sshd is patched to integrate with systemd, the system-and-service manager that boots most modern Linux machines, so that it can report its status. That integration means sshd links against libsystemd, and libsystemd in turn links against liblzma. So a compression library ends up loaded into the memory of the very process that guards remote access to the machine. That indirect dependency, sshd → libsystemd → liblzma, is the bridge the attacker built the entire operation to cross, as the technical analyses that followed made clear.

The long con

The technically astonishing part of this story is not the malware. It is the patience. Around early 2021, an account under the name "Jia Tan" (username JiaT75) appeared and began contributing to open-source projects. Kaspersky's researchers place the GitHub account's creation at 26 January 2021. The early contributions were unremarkable and even, in retrospect, faintly suspicious in small ways, but the point was to build a track record. This is the oldest trick in intelligence work applied to code: establish a legend, a plausible history, before you need it. By 2022, Jia Tan was submitting patches to XZ Utils itself. The project had essentially one maintainer, a Finnish developer named Lasse Collin, who had kept it running for years largely alone and unpaid. And this is where the operation showed its real shape. According to Russ Cox's meticulous timeline of the attack, a cast of other accounts materialised to lean on Collin. An account named "Jigar Kumar" started complaining, publicly and repeatedly, that Collin was too slow. On 22 April 2022, Kumar wrote: "Patches spend years on this mailing list. There is no reason to think anything is coming soon." A month later, on 27 May: "Over 1 month and no closer to being merged. Not a surprise." By 7 June, the message had a target: "Progress will not happen until there is new maintainer." Then a second account, "Dennis Ens," joined in. On 21 June 2022, playing a different note, it turned to Collin's evident exhaustion: "I am sorry about your mental health issues, but its important to be aware of your own limits. Why not pass on maintainership for XZ for C so you can give XZ for Java more attention?" Collin, who had already told the list that he was dealing with long-term health problems and limited time, replied on 29 June 2022 with a line that reads very differently now than it did then: "Jia Tan may have a bigger role in the project in the future. He has been helping a lot off-list and is practically a co-maintainer already." That was the hinge. The pressure accounts had done their job. "Jigar Kumar" was, as Evan Boehs documented in his widely cited writeup, never heard from again. Neither was "Dennis Ens." Their email addresses used the same tell-tale name-plus-number-at-a-free-provider pattern, they appeared only in XZ discussions, and they vanished the moment their purpose was served. The most economical explanation, though it has never been proven in court, is that they were sock puppets: fake personas run by the same operation as Jia Tan, engineered to manufacture the appearance of community consensus that Collin should share control. It worked without any hacking at all. No stolen credentials, no exploited server. Just a tired volunteer, a fabricated chorus telling him he was failing, and a helpful newcomer who was always there to take the load.

Building the trapdoor

Over 2023, Jia Tan consolidated real authority. Commits merged. The contact address that Google's OSS-Fuzz project (an automated bug-finding service) used for XZ was changed to point at Jia Tan rather than Collin. In March 2023, Jia Tan cut the 5.4.2 release. By early 2024, Jia Tan controlled the project's website and its release process. A trusted insider, in other words, now held the keys. The backdoor arrived in pieces, which is part of what made it so hard to spot. This is worth dwelling on, because it exploits a gap that most people, even most programmers, do not know exists. When you look at a project on GitHub, you are looking at its source code repository. But when a Linux distribution builds a package, it usually does not build from the raw repository. It builds from a "release tarball," a packaged archive the maintainer prepares. In principle the tarball should just be the source code. In practice, for historical reasons involving the ancient build tooling called Autotools, release tarballs routinely contain extra generated files that are not in the git repository. That difference is a blind spot. Reviewers watch the repository. The tarball gets less scrutiny. The attacker hid the trigger there. As Freund reconstructed in his disclosure, the release tarballs for versions 5.6.0 and 5.6.1 contained a modified build script (build-to-host.m4) that existed only in the tarball, not in the public repository. During compilation, that script quietly sprang to life and pulled its real payload out of two files that had been sitting in the repository in plain sight, disguised as corrupted test data for the compression code: bad-3-corrupt_lzma2.xz and good-large_compress.lzma. Test suites are full of deliberately malformed files, so binary junk that fails to decompress cleanly raises no eyebrows. Here, that "junk" was the backdoor, encrypted and waiting. The extracted script deobfuscated itself in stages, checked that it was building the right kind of target (x86-64 Linux, glibc, built as a Debian or RPM package), and if everything matched, patched the compiled liblzma to insert malicious machine code. The whole apparatus was designed to activate only during a real distribution build and to leave the source tree looking innocent.

What the backdoor did

Once loaded inside sshd, the malicious code used a low-level Linux mechanism called IFUNC (an "indirect function" resolver, a legitimate feature that lets a library pick an optimised version of a function at load time) to hijack the process. Specifically, as reverse engineers established, it hooked RSA_public_decrypt, a function OpenSSH calls while checking cryptographic keys during login. From then on, every login attempt was inspected by the attacker's code. The backdoor pulled data out of the certificate presented by whoever was connecting, checked it against a fingerprint, decrypted it with a hard-coded ChaCha20 key, and verified an Ed448 signature against a public key baked into the malware. Ed448 and ChaCha20 are strong, modern cryptographic algorithms. The consequence of using them here is important: only someone holding the matching private key, that is, the attacker, could produce a valid payload. This was not a backdoor anyone could walk through once they knew about it. It was locked, and only its author had the key. If the signature checked out, the payload it carried, a string of shell commands, was handed to the system to execute, before the login had even completed. That is the worst category of vulnerability there is: unauthenticated remote code execution. An attacker could run arbitrary commands as the all-powerful root user, on any exposed server running the backdoored build, without needing a valid password or key, and could do so quietly, leaving little trace in the logs.

How close it came, and a common misconception

It is tempting to say the backdoor "infected" Linux. It did not, and the distinction matters. Versions 5.6.0 and 5.6.1 were released in February and March 2024 and made it into the fast-moving, bleeding-edge branches of several distributions: Debian's sid, Fedora's Rawhide and the beta of Fedora 40, openSUSE Tumbleweed, Kali Linux, and Arch. It did not reach the stable, long-term releases that run the overwhelming majority of production servers, because those releases move slowly on purpose and had not yet pulled the poisoned version. Freund himself noted in his disclosure that the affected versions had "not yet widely been integrated by linux distributions." Debian had picked up 5.6.1 only days before he raised the alarm, pushed along by yet another account, "Hans Jansen," that lobbied for the upgrade and then disappeared. So the accurate framing is a near miss, not a breach. This was arguably the most dangerous supply-chain attack in the history of open source precisely because of how close it came while affecting almost no one in the end. The operation was days to weeks away from landing in the stable releases that would have carried it onto a substantial share of the internet's servers. It was caught in the narrow window between shipping and going mainstream, and it was caught by luck wearing the costume of diligence: one engineer who could not let a 500-millisecond mystery go. The clean-up was fast. CISA and distributions urged everyone to downgrade to a known-good 5.4.x release, GitHub suspended the XZ repository and the relevant accounts, and Lasse Collin, blindsided, worked to audit and reclaim his own project. Version 5.6.2, with the backdoor removed, followed on 29 May 2024.

Who was "Jia Tan"?

Honestly, we do not know, and anyone who tells you otherwise is guessing. What the evidence supports is a strong inference of professionalism. The multi-year timeline, the disciplined use of sock puppets, the deep knowledge of the Linux build pipeline and of sshd's internals, the careful cryptographic locking of the backdoor so that no one but the author could use it, and the operational patience all point away from a lone hobbyist and toward a well-resourced group. Kaspersky's analysis stops short of naming anyone and lays out several possibilities, from a coordinated team to a single operator running many masks. Many researchers regard the sophistication as consistent with a state-sponsored intelligence operation, comparable in ambition to the SolarWinds compromise, but that remains an assessment, not a confirmed attribution. There are teasing forensic breadcrumbs, and they mostly cancel out. Jia Tan's commits were configured for a UTC+8 time zone, suggesting East Asia. But analysts noticed that the actual pattern of activity fit Eastern European working hours better, with the commit timestamps looking deliberately shifted, and that the account went quiet during Eastern European public holidays. The persona names spanned several regions in a way that felt, as Kaspersky put it, "a bit forced." In other words, the geography was almost certainly a costume. Nearly three years after the discovery, no individual has been publicly identified or charged.

The uncomfortable lesson

The reflex after an incident like this is to reach for a technical fix, and several are underway: reproducible builds that let anyone verify a binary matches its source, tighter scrutiny of the gap between repositories and release tarballs, and tools to flag suspicious build-time behaviour. All of it helps. None of it addresses what actually failed. What failed was a social system. A piece of code that helps run a meaningful share of the world's computers was maintained by one person, for free, in his spare time, while his health suffered, and the attack vector was not a buffer overflow but that person's isolation and exhaustion. The manufactured impatience of "Jigar Kumar," the false sympathy of "Dennis Ens," the tireless helpfulness of "Jia Tan": these were tools aimed at a human being with too much responsibility and too little support. There is a well-known xkcd cartoon picturing all modern digital infrastructure as a precarious tower resting on a tiny block that "some random person in Nebraska has been thanklessly maintaining since 2003." XZ made the joke literal, and then showed what happens when an adversary decides to lean on that block on purpose. The thing to watch is not whether this specific trick gets patched. It is whether the money, staffing, and governance around critical open-source projects change enough that the next Lasse Collin is not standing alone when the next Jia Tan comes to help. As of late 2026, that work has begun, unevenly. The attack was caught by an accident of curiosity. That is not a security model. It is a warning that the next one may be quieter, and that we should not count on someone benchmarking a database at exactly the right moment twice.

---

Sources

1. openwall / oss-security, "backdoor in upstream xz/liblzma leading to ssh server compromise" (Andres Freund's original disclosure), 2024
2. Wikipedia, "XZ Utils backdoor", 2024–2026
3. Russ Cox (research!rsc), "Timeline of the xz open source attack", 2024
4. Evan Boehs, "Everything I Know About the XZ Backdoor", 2024
5. Kaspersky Securelist, "The XZ backdoor story, part 2: social engineering", 2024
6. seclists.org / oss-sec, "Re: backdoor in upstream xz/liblzma leading to ssh server compromise" (technical payload analysis), 2024
7. Akamai Security Research, "XZ Utils Backdoor: Everything You Need to Know, and What You Can Do", 2024
8. The Intercept, "The Other Players Who Helped (Almost) Make the World's Biggest Backdoor Hack", 2024
9. arXiv, "On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ", 2024
10. xkcd, "Dependency" (comic #2347), 2020