The XZ Utils Backdoor: How a Multi-Year Social Engineering Campaign Almost Backdoored the Internet

On March 29, 2024, a Microsoft software engineer named Andres Freund posted a message to the oss-security mailing list that would set off alarms across the entire technology industry. While investigating why SSH logins on a Debian test system were running about half a second slower than expected and burning unusual amounts of CPU, Freund traced the behavior to the XZ Utils data compression library — and discovered that recent versions contained a deliberately planted backdoor. The vulnerability was assigned CVE-2024-3094 and given a CVSS score of 10.0, the maximum possible severity.

Unlike the SolarWinds SUNBURST or 3CX attacks, the XZ backdoor was caught before it reached most production systems. But the story behind it — a patient, multi-year campaign to socially engineer control of a critical open-source project — is arguably more unsettling than any breach that succeeded. It exposed a structural weakness in the software supply chain that no security questionnaire would ever have detected.

What XZ Utils Is and Why It Mattered

XZ Utils is a small, ubiquitous set of open-source tools and a library (liblzma) for the XZ/LZMA compression format. It is bundled in virtually every major Linux distribution and countless other Unix-like systems. Software this foundational rarely makes headlines — it simply works, quietly, everywhere. That ubiquity is exactly what made it an attractive target. A backdoor in XZ Utils was, in effect, a potential master key to a large fraction of the servers running the internet.

For years, XZ Utils was maintained largely by a single volunteer, Lasse Collin. This is not unusual. An enormous amount of critical digital infrastructure rests on open-source components maintained by one or two unpaid individuals in their spare time — a structural fragility the industry had been warned about since the Log4Shell crisis of 2021.

The Long Con: A Maintainer Takeover

What makes the XZ incident extraordinary is that it was not a smash-and-grab exploitation of a coding mistake. It was a deliberate, slow-burn social engineering operation that played out over more than two years.

According to public timelines reconstructed after the discovery, a GitHub account using the name "Jia Tan" (JiaT75) was created in 2021 and began contributing to open-source projects, building a track record of legitimate-looking commits. Beginning around 2022, the XZ project's sole maintainer came under sustained pressure from a chorus of accounts — with names like "Jigar Kumar" and "Dennis Ens" — who filed complaints, demanded faster feature development, and pushed for an additional maintainer to be added because the project was allegedly stagnating. Security researchers widely believe these were sock-puppet accounts coordinated to manufacture the appearance of community pressure.

The campaign worked. "Jia Tan" was gradually granted more trust and responsibility, eventually becoming a co-maintainer with commit access and release authority. In late 2022, the project's bug-reporting contact was even changed to an alias that routed to both Collin and Jia Tan. By 2023, Jia Tan was cutting official releases. The attacker had achieved what no external hacker could: legitimate, trusted control over the supply chain itself.

The Backdoor

In February 2024, the malicious payload was introduced in XZ Utils versions 5.6.0 and 5.6.1. The implementation was sophisticated and deliberately obscured. The backdoor code was not committed in plain sight to the source repository; instead, it was hidden inside the release tarballs — the packaged source archives that distributions actually build from — using a modified build script (build-to-host.m4) and test files disguised as binary test fixtures.

The payload's target was OpenSSH, the standard tool for remote server access. OpenSSH does not normally use liblzma, but a patch applied by several major Linux distributions links it to the systemd library, which in turn pulls in liblzma. The backdoor hooked into the SSH authentication process so that an attacker holding a specific private cryptographic key could execute arbitrary commands on the affected server — before authentication, remotely, with no credentials. In practical terms, it was a near-perfect, distribution-wide remote code execution backdoor.

The Near-Miss

The reason XZ Utils is remembered as a near-miss rather than a catastrophe is timing. The backdoored versions had been pushed into the rolling and testing branches of major Linux distributions but had not yet propagated into the stable, long-term-support releases that run the vast majority of production servers. Had Freund not noticed a fraction-of-a-second performance anomaly and chosen to investigate it — an act of curiosity, not a security control — the backdoored versions would likely have flowed into stable releases over the following months, reaching an enormous installed base before anyone knew to look.

That the global software supply chain was saved by one engineer's diligence, rather than by any systematic defense, is the most sobering takeaway of the entire episode.

Why This Is a Third-Party Risk Problem

It is tempting to file XZ Utils under "open-source security" and move on. But for anyone responsible for third-party risk management, the incident maps directly onto vendor risk in three ways:

1. Your vendors are built on the same fragile foundations

Every SaaS provider, every appliance vendor, and every managed service in your portfolio almost certainly ships open-source components like XZ Utils inside their products. A backdoor in a shared upstream dependency becomes your exposure the moment a vendor builds it into the software you rely on. This is the essence of fourth-party and nth-party risk: the components your vendors depend on are part of your attack surface, whether you can see them or not.

2. SBOMs are how you find out you are exposed

When CVE-2024-3094 was disclosed, the organizations that could answer "are we affected?" in minutes were the ones that maintained a Software Bill of Materials (SBOM) for their environment and demanded SBOMs from their vendors. Those without component inventories spent days manually hunting. The XZ incident is one of the clearest arguments yet for the SBOM requirements that emerged after SolarWinds — and for making vendor SBOM disclosure a standard part of due diligence.

3. Self-attestation cannot catch a trusted-insider supply chain attack

No questionnaire asks a vendor, "Has a patient adversary spent two years socially engineering their way into maintainer status on one of your upstream dependencies?" Point-in-time, self-reported assessments are blind to this entire class of attack. Managing it requires continuous monitoring, dependency intelligence, and a healthy assumption that any component — no matter how trusted — can be compromised.

What Changed After XZ

The XZ incident accelerated conversations that had been simmering since Log4Shell and SolarWinds. It sharpened focus on the sustainability of open-source maintenance, prompting renewed funding initiatives for critical projects and the people who maintain them. It strengthened the case for reproducible builds and for scrutinizing release artifacts rather than trusting that a published tarball matches the public source repository. And it gave regulators and procurement teams another concrete example to point to when requiring software transparency and secure development attestations from vendors.

But the underlying condition has not been solved. Vast swaths of the digital economy still rest on under-resourced open-source projects, and the trust model that the XZ attacker exploited remains largely intact. The next "Jia Tan" may already be building credibility somewhere in a dependency your vendors rely on.