> ## Documentation Index
> Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# xz-utils Backdoor (CVE-2024-3094): A Textbook Supply-Chain Attack

> A deliberate backdoor planted in xz-utils 5.6.0 and 5.6.1 targeted OpenSSH via systemd. Caught early, narrow blast radius — but the lesson is huge.

*Published on April 2, 2024*

<Warning>
  **CVE-2024-3094.** A backdoor was deliberately planted in versions **5.6.0** and **5.6.1** of the `xz-utils` library. Caught on March 29, 2024 by a curious Postgres developer investigating unusual SSH connection times, the attack was stopped before it reached stable distributions. But it could have made it — and that is the real story.
</Warning>

## What happened

Over the course of two years, a contributor under the pseudonym **Jia Tan** earned the trust of the `xz-utils` community, eventually becoming co-maintainer. With that role, they progressively injected, across several scattered commits, an obfuscated payload into the `liblzma` library.

At build time, the payload:

1. Detects that it is being compiled in a context that will later be loaded by `sshd` via `systemd` (distributions that patch `sshd` to depend on `libsystemd`, which itself depends on `liblzma`).
2. Hooks specific internal `sshd` functions at startup.
3. Lets anyone in possession of a specific key bypass SSH authentication **as any user, with no log trace**.

In other words: universal root access on tens of millions of servers, through a backdoor that classical security tooling would not have flagged.

## Why this did not become a global disaster

Andres Freund, a Postgres maintainer at Microsoft, was debugging suspicious 500ms SSH connection times. Following the trail, he eventually surfaced the payload — and reported to `oss-security` on March 29, 2024.

At that point, versions 5.6.0 and 5.6.1 only shipped in:

* **Fedora 41 and Rawhide**
* **Debian testing/unstable/experimental**
* **openSUSE Tumbleweed**, **openSUSE MicroOS**
* **Arch Linux**
* A few *bleeding edge* macOS channels via Homebrew

No stable production distribution shipped those versions. The actual compromise perimeter was tiny.

## Are you affected?

Check your installed `xz` version:

```bash theme={null}
xz --version
```

If the output shows **5.6.0** or **5.6.1**, you are potentially exposed.

```bash theme={null}
# Debian/Ubuntu
dpkg -l xz-utils liblzma5

# Fedora/RHEL/AlmaLinux/Rocky
rpm -qa | grep -i xz

# Arch
pacman -Q xz
```

## What to do

### If you are on a 5.6.x version

Downgrade to 5.4.x (the last clean release) immediately. Every affected distribution has shipped fixed packages by now. On Arch:

```bash theme={null}
sudo pacman -Syyuu  # full upgrade
```

On Debian unstable/testing:

```bash theme={null}
sudo apt update && sudo apt install --reinstall xz-utils liblzma5
```

### If you are on a stable distribution

You are not affected. 5.6.0/5.6.1 never reached Debian stable, Ubuntu LTS, RHEL stable, etc.

### Either way

Use the episode to ask the broader question: **which packages do you build from source or install from unofficial repos?** The xz-utils attack exposed how fragile a model can be where a single maintainer of a critical library can compromise the planet. That calls for:

* Strict reduction of internally-built dependencies.
* Use of signed, auditable mirrors.
* Tighter review of critical transitive dependencies (crypto libs, compression libs, drivers, etc.).

## Takeaways

xz-utils is not a classical "vulnerability": it is a **supply-chain attack** on open-source software, with long-running social engineering (two years of work) and a sophisticated technical payload. Practical lesson: update to a clean version. Strategic lesson: trust in open-source code is not just "it's public". Audit what you ship.

For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net).