The XZ Utils Backdoor Explained: The Supply Chain Attack That Almost Broke Linux
The XZ Utils Backdoor Explained: The Supply Chain Attack That Almost Broke Linux
TLDR: In early 2024, a mysterious developer known as "Jia Tan" spent over two years making legitimate, helpful contributions to XZ Utils — a compression library installed on billions of Linux systems. After earning maintainer trust, they inserted a backdoor into the release package that would have allowed remote code execution on any internet-facing Linux server running OpenSSH. It was caught by a Microsoft engineer named Andres Freund who noticed SSH logins were 500 milliseconds slower than normal. It was that close. This is what a software supply chain attack looks like — and why it's now #3 on OWASP 2025.
It Started With Being Helpful
October 2021. A GitHub account named JiaT75 appears and begins contributing to open source projects. Small fixes. Clean code. Responsive on issue threads. Nothing suspicious — this is how open source works. Good contributors show up and start earning trust.
Over the next several months, Jia Tan gravitates toward XZ Utils — a compression library so foundational to Linux that it ships pre-installed on essentially every distribution. The sole maintainer, Lasse Collin, has been running the project alone for years. He's burned out. The mailing list has started filling up with pressure: the project needs more active maintainers, releases are too slow, progress is stalling.
What nobody knew at the time: those pressure accounts — with names like Jigar Kumar, krygorin4545, and misoeater91 — were almost certainly sock puppets. Fake identities created to manufacture the appearance of community frustration, engineered specifically to justify handing control to Jia Tan.
It worked. By late 2022, Jia Tan had commit access. By 2024, they were effectively running the project. Out of all contributions made during this period, only eight commits were malicious. The rest were legitimate improvements — 2.6 years of sustained, patient engagement to earn the trust required to distribute a backdoor.
The Backdoor Itself
In February 2024, Jia Tan released XZ Utils version 5.6.0. On the surface: a routine update with performance improvements. Underneath: one of the most sophisticated backdoors ever introduced to an open source project.
The backdoor was a masterpiece of obfuscation. It wasn't in the source code visible on GitHub. Instead, it was hidden in binary test files that looked like innocent data blobs for verifying the compressor. The build system was the weapon — when the package was built as a tarball for distribution, scripts extracted the malicious payload from the test files and injected it into the build process.
The target was OpenSSH. On certain Linux configurations where SSH uses the systemd-patched version of OpenSSH (notably Debian and Fedora), SSH depends on liblzma. The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on the affected Linux system.
In plain terms: if you were running a Debian or Fedora server with the compromised XZ version, someone holding the private key could silently log into your server — bypassing authentication entirely — without leaving a trace in your logs.
Governments. Banks. Cloud infrastructure. Every Linux server running the affected version, potentially open to a single attacker.
How It Was Caught — By Accident
It started with a 500-millisecond delay. In late March 2024, Andres Freund, a PostgreSQL developer at Microsoft, noticed something odd: SSH logins on his Debian unstable machine were taking just half a second longer than usual.
Most people would have chalked this up to a flaky network connection and moved on. Freund didn't. He dug into the CPU usage, found Valgrind errors pointing to liblzma, and traced the anomaly back to the XZ Utils release tarball. On March 29, 2024, he posted his findings to the Openwall security mailing list.
Within hours, GitHub suspended Jia Tan's account. The XZ repository was locked. Red Hat, Debian, and every major Linux distribution issued emergency security advisories. The attack was stopped.
But here's what should genuinely concern every engineering leader: without the discovery of this SSH delay and various Valgrind test errors, the community may not have discovered this vulnerability until it had run its course, infecting untold thousands or millions of machines. The backdoor had already made it into Fedora Rawhide, Fedora 40 beta, and several rolling Debian distributions. It was days away from stable release across the Linux ecosystem.
One engineer. Half a second. That's the margin.
Why Your Dependencies Are Your Code
Jia Tan's identity remains officially unknown. Security researchers have noted that their active hours align with Central European working hours rather than the stated Chinese timezone. Their operational patience — years of legitimate work before a single malicious commit — is usually the realm of state-sponsored threat actors. Many researchers point toward APT29 (Cozy Bear), the same group behind SolarWinds.
SolarWinds. XZ Utils. These aren't isolated incidents — they're the same playbook applied to different targets. Compromise the supply chain, and you compromise every downstream customer at once. It's more efficient than attacking individual organisations one by one.
This is exactly why Software Supply Chain Failures entered the OWASP Top 10 2025 at #3 — with the highest average impact score of any category. The attacks are rare enough to avoid consistent statistical detection, but when they succeed, the blast radius is measured in millions of systems.
Your application likely has hundreds of dependencies. Many of those dependencies have their own dependencies. Some of those projects are maintained by a single volunteer who's been doing it for years and is, frankly, exhausted. XZ shattered the illusion that "many eyes make all bugs shallow." It exploited the burnout of unpaid maintainers and the blind trust placed in upstream code.
We've written before about how secrets in your own code create exposure. The supply chain problem is the same vulnerability extended outward — not just your code, but every line of code your code depends on.
What You Can Actually Do
You cannot audit every dependency individually. But you can significantly reduce your exposure with a few structural changes.
Create and maintain a Software Bill of Materials (SBOM). An SBOM is an inventory of every component in your application — direct and transitive dependencies, versions, and known vulnerabilities. Tools like Syft generate these automatically. You cannot defend a dependency you don't know you have.
Pin your dependency versions and verify checksums. Don't use floating version ranges (^1.2.0). Pin exact versions and verify cryptographic checksums of packages at build time. If a package changes unexpectedly between builds, that's a signal worth investigating.
Run automated dependency scanning in your CI pipeline. Tools like Snyk, Dependabot, and OWASP Dependency-Check flag known CVEs in your dependencies and alert when new vulnerabilities are published. For the XZ attack specifically, behavioral detection — not static scanning — was what worked. Consider integrating runtime anomaly detection for production services.
Watch for what XZ exploited: binary files in source repos. Binary blobs in a source code repository are a significant red flag. They can't be reviewed meaningfully, and as XZ showed, they can be used to carry payloads that never appear in the human-readable code.
For a full picture of your cloud dependency exposure, our cloud security review covers the pipeline and infrastructure layer too.
How Kuboid Secure Layer Can Help
A thorough security assessment doesn't stop at your own code. Our web application and infrastructure reviews include dependency tree analysis — identifying outdated packages, known CVEs in transitive dependencies, and supply chain exposure points that automated tooling alone won't surface.
If you want to know what's actually in your application's dependency graph before someone else finds out, let's talk.
The XZ attack nearly worked because one maintainer was overwhelmed and alone. Have you ever thought about who actually maintains the critical open source packages your application depends on? Drop a comment — it's a question more engineering teams should be asking.
Kuboid Secure Layer provides web application penetration testing and security assessments for growing businesses. Learn more at kuboid.in/services.
