Feb 26, 2026·5 min read·69 visits
A rogue maintainer planted a backdoor in the XZ compression library (liblzma). It hooks SSH authentication to allow remote code execution via a magic private key. If you run a bleeding-edge Linux distro (Fedora Rawhide, Kali, Debian Sid) with XZ 5.6.0+, you are compromised. Stable distros (RHEL, Ubuntu LTS) largely dodged the bullet.
In one of the most sophisticated supply chain attacks in history, a maintainer persona known as 'Jia Tan' spent years building trust within the XZ Utils project before injecting a hidden backdoor into the build process of versions 5.6.0 and 5.6.1. This backdoor, hidden within binary test files and extracted via obfuscated M4 macros, hooks into the OpenSSH daemon (sshd) via systemd notification integration. It allows an attacker possessing a specific Ed448 private key to bypass authentication and execute arbitrary code as root on the target machine, effectively granting a master key to any infected Linux server exposed to the internet.
Most critical vulnerabilities are found by automated fuzzers, massive bug bounty programs, or dedicated security teams. This one? It was found because Andres Freund, a PostgreSQL developer at Microsoft, is the kind of obsessive engineer who notices when a login takes 500 milliseconds longer than it should.
While benchmarking PostgreSQL, Freund noticed sshd was eating up a surprising amount of CPU cycles during authentication. Most people would blame network jitter or a bad config. Freund broke out perf and valgrind. He found that liblzma—a compression library that has absolutely no business being involved in SSH crypto operations—was somehow intercepting calls.
This wasn't a buffer overflow or a logic error. This was a expertly crafted, deliberate backdoor. It turns out that libsystemd links to liblzma for journal compression, and sshd links to libsystemd for notification support. That tenuous dependency chain was the highway the attacker used to drive a tank through the front door of Linux security.
The brilliance of this attack lies in where the malicious code lived. If you looked at the GitHub repository for XZ Utils, everything looked clean. The backdoor wasn't in the C source files. It wasn't even in the build scripts committed to the repo.
The attacker, operating under the handle "Jia Tan," introduced the backdoor in the release tarballs—the packaged source code files that package managers download to build the software. He inserted a modified build-to-host.m4 file into the tarball that didn't match the repository.
But where was the payload? It was hidden in plain sight inside "test" files committed to the repo: tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma. To a casual observer (and git), these were just binary blobs for unit testing compression handling. In reality, they were sliced-up parts of a pre-compiled object file. The malicious M4 script would act as a linker, stitching these blobs together during the ./configure phase to form the backdoor.
> [!NOTE] > This is a textbook example of why "reproducible builds" are critical. If the artifact generated from the source code doesn't match the distributed binary, you have a problem.
So how do you get a compression library to hijack an SSH session? You use the GNU Indirect Function (IFUNC) mechanism. IFUNC is a feature in glibc that allows a developer to create multiple versions of a function (optimized for different CPUs) and have the system choose the best one at runtime.
Jia Tan's backdoor replaced the legitimate IFUNC resolvers for crc32_resolve and crc64_resolve with malicious ones. When liblzma initializes, the dynamic linker calls these resolvers to decide which CRC function to use. The backdoor uses this opportunity to scan the Global Offset Table (GOT) of the hosting process (i.e., sshd).
It looks specifically for the symbol RSA_public_decrypt. Once found, it rewrites the memory address of that symbol to point to its own internal function. Now, every time sshd tries to decrypt a public key during user authentication, it unwittingly hands the data to the attacker's code first.
The backdoor doesn't just let anyone in. It's not a hardcoded password like "solarwinds123". It is a sophisticated cryptographic bypass. The malicious hook inspects the incoming SSH public key payload. It looks for a specific hidden signature signed by the attacker's own Ed448 private key.
If the signature is present and valid:
sshd process (which, at this stage of authentication, is usually root).If the signature is invalid or missing (which is the case for 99.999% of legitimate logins), the backdoor simply calls the original RSA_public_decrypt function. The user logs in normally, and the system behaves exactly as expected—except for that tiny, 500ms delay that Andres Freund noticed. This fail-open design meant the backdoor could exist in production for months without causing crashes or obvious errors.
This vulnerability is terrifying not because of the technical sophistication (though that was high), but because of the social engineering. Jia Tan spent two years contributing to the project, fixing bugs, and helping the original burnt-out maintainer, Lasse Collin. He earned the "commit bit" the hard way: by doing the work nobody else wanted to do.
This exposes a fundamental crack in the foundation of modern digital infrastructure: we rely on code written by unpaid volunteers who are often overworked and underappreciated. Major corporations build billion-dollar empires on top of libraries like XZ, ImageMagick, and Log4j, often without contributing a cent back to maintenance or security audits.
If this backdoor had made it into Debian Stable or RHEL (Red Hat Enterprise Linux), it would have granted the attackers a skeleton key to a massive chunk of the internet's servers, cloud infrastructure, and enterprise backends. We dodged a nuclear bullet by a matter of weeks.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
xz-utils Tukaani Project | 5.6.0 | 5.6.2 |
xz-utils Tukaani Project | 5.6.1 | 5.6.2 |
| Attribute | Detail |
|---|---|
| Attack Vector | Supply Chain / Network |
| CWE | CWE-506 (Embedded Malicious Code) |
| CVSS | 10.0 (Critical) |
| Impact | Remote Code Execution (RCE) / Auth Bypass |
| Mechanism | IFUNC Hooking via liblzma |
| Target | sshd (via libsystemd dependency) |
The product contains code that appears to be malicious in nature.