The XZ Backdoor: How a Trusted Maintainer Nearly Opened a Secret Door Into Linux

A patient supply-chain operation hid malicious code inside an ordinary compression library — and was exposed because one developer refused to ignore a small performance anomaly

Some of the most important security discoveries begin with an alarm, a ransom note or a server going dark. The XZ Utils backdoor began with something less dramatic: SSH logins were behaving oddly.

In March 2024, software engineer Andres Freund was investigating unusually high CPU use and strange errors on Debian testing systems. Remote logins were slightly slower than expected. The difference was small enough to dismiss as an irritating regression, but persistent enough to deserve another look.

That decision exposed one of the most sophisticated software supply-chain attacks ever publicly documented.

Malicious code had been concealed inside release packages for XZ Utils, a widely used set of compression tools and libraries found throughout the Linux ecosystem. Under carefully selected conditions, the altered library could interfere with the OpenSSH server and potentially allow an attacker holding a secret cryptographic key to execute commands without completing normal authentication.

The code was dangerous. The route used to place it there was more unsettling still.

The quiet library beneath modern systems

XZ Utils compresses and decompresses data, much as gzip and similar tools do. Its liblzma library is used by operating systems, package managers and other software that handles the .xz format.

It does not look like an obvious strategic target. That apparent dullness was part of its value.

Modern infrastructure depends on thousands of small libraries that quietly perform routine work. Many are maintained by only one or two people, sometimes in their spare time, while major companies and public bodies depend on the results.

The compromised releases were XZ Utils 5.6.0, published on 24 February 2024, and 5.6.1, published on 9 March. Parts of the malicious payload were hidden in files presented as test data. A modified build-system file in the published release archives then extracted and inserted the payload during compilation.

Crucially, the activating instructions were not present in the normal Git source in the same form. The trap lived partly in the difference between the repository reviewers inspected and the release tarballs distributors downloaded.

Trust was the first system compromised

The account associated with the attack used the name “Jia Tan” and the GitHub handle JiaT75. The real person — or group — behind that identity has never been publicly confirmed.

The persona appeared in the open-source ecosystem in late 2021 and later became an active XZ contributor. The work was not an obvious burst of malicious code. It included legitimate fixes, maintenance and patient participation in project discussions.

Over time, Jia Tan gained credibility and responsibility. By late 2022, the account was recognised as a co-maintainer. In March 2023, Jia Tan produced an XZ release. By early 2024, the account had enough authority to publish the versions carrying the backdoor.

This was not a stolen password followed by a hurried malicious commit. It was a long investment in reputation.

Mailing-list records also show pressure being applied to XZ’s original maintainer, Lasse Collin, by other accounts complaining about slow development and calling for additional maintainers. Researchers have suggested that some may have been false identities supporting the takeover, although coordination has not been conclusively proven.

The attackers appear to have understood that an exhausted maintainer could be a more useful target than a hardened server. They exploited workload, trust and the desire to keep a valuable project alive.

How the backdoor stayed hidden

The malicious build process was highly selective. It targeted particular 64-bit Linux environments and depended on a combination of build tools, packaging choices and system components. The intended route involved systems where OpenSSH’s server process was connected indirectly to liblzma through systemd-related dependencies.

When those conditions were met, the modified library could manipulate functions used inside the SSH server. A specially crafted connection, authorised with the attacker’s private key, could trigger unauthorised command execution.

The selectivity reduced noise. The code would not behave maliciously everywhere, helping it avoid attention on unsupported systems and in many automated tests.

The concealment was equally deliberate. Binary test files carried hidden components, while the release archive supplied the build instruction needed to assemble them. A reviewer examining readable source code alone could therefore miss the final mechanism.

It was less like hiding a weapon in one box than distributing harmless-looking pieces that became a weapon only when unpacked in the correct room.

The small anomaly that exposed everything

Freund noticed that SSH authentication consumed more CPU than expected and produced unusual Valgrind results. He followed the behaviour through the system until it led to liblzma, then compared packages, build scripts and release contents.

On 27 March 2024, he contacted Debian’s security team. Red Hat and other organisations joined a coordinated investigation. On 29 March, Freund published his findings to the Openwall oss-security mailing list, and distributors began removing or downgrading the affected packages.

Luck played a role: the performance overhead was not the attacker’s intended calling card. Yet the discovery was also a product of deep systems knowledge and disciplined debugging. Freund did not begin by assuming a nation-state operation. He followed a small inconsistency until the ordinary explanations stopped working.

Security tooling matters. So does the engineer who asks why a process is taking slightly longer than yesterday.

Was the whole Internet really weeks from disaster?

The potential impact was enormous, but the immediate exposure in March 2024 was narrower than some headlines suggested.

Affected packages had reached Debian unstable and testing environments, Fedora Rawhide and Fedora 40 beta builds, as well as some rolling or pre-release distribution channels. Stable Red Hat Enterprise Linux releases were not affected. Ubuntu reported that no released Ubuntu version contained the compromised package, while Debian’s stable releases were also outside the affected range.

The exploit additionally required a particular technical configuration. Installing XZ 5.6.0 or 5.6.1 did not automatically make every Linux device remotely exploitable.

Nevertheless, the alarm was justified. New packages move from development branches into stable releases, container images and long-lived server deployments. Had the compromise remained undiscovered, it could have entered far more production systems under the authority of a legitimate upstream project.

The catastrophe was prospective rather than completed. The attackers had built the delivery mechanism and were approaching wider distribution when they were stopped.

A threat with a long memory

Removing a malicious package from active repositories does not erase every copy already produced.

In August 2025, security company Binarly reported finding historical Debian-based Docker images that still contained compromised XZ packages. The conditions required to exploit the backdoor inside those containers were considered highly unlikely, and the finding did not prove that the images had been used successfully in attacks.

It did reveal a broader problem. Software artefacts are cached, mirrored, inherited as base layers and kept for reproducibility. A package removed from today’s repository can remain embedded in yesterday’s build.

Security teams therefore need inventories covering container registries, build caches and archived artefacts — not merely machines receiving current updates.

Who was behind Jia Tan?

The patience and technical sophistication of the campaign led many researchers to suspect a state-backed group. The operator maintained a credible identity for years, contributed substantial legitimate work and built a passive backdoor intended for quiet, targeted access rather than noisy mass exploitation.

Those characteristics support suspicion, not attribution.

As of June 2026, no government or security organisation has publicly confirmed the real identity behind Jia Tan or conclusively assigned the operation to a particular country. Claims involving China, Russia, North Korea or another state remain theories based on tradecraft and circumstantial clues.

In a case built around manufactured trust, the attacker’s biography should be treated as another potentially hostile artefact.

What the XZ incident teaches

The incident challenged a comforting simplification: open-source software is safe because anyone can inspect it.

Anyone can inspect it. That does not mean somebody always does.

Readable source code also provides limited protection when malicious behaviour is divided between binary test data, generated files, build scripts and downstream integration. The object that must be trusted is not merely the repository. It is the whole path from contributor identity to code review, release archive, build environment, package repository and deployed machine.

OpenSSF and the OpenJS Foundation later warned maintainers about patterns resembling the XZ campaign: persistent newcomers seeking elevated access, endorsements from unknown accounts, unexplained urgency, opaque binary files, obfuscated changes and deviations from normal build procedures.

Defences include second-person code review, protected branches, strong authentication, signed commits and releases, reproducible builds, comparisons between release archives and repository contents, and better software provenance.

Yet process cannot solve a human resource problem on its own. Companies routinely build profitable services on components maintained by a handful of overworked volunteers. Funding, governance support, independent audits and succession planning are security controls just as surely as firewalls and vulnerability scanners.

The larger warning

The XZ backdoor did not bring down the Internet. It revealed how someone might patiently prepare to enter through one of its least guarded doors.

The attacker’s most effective exploit was not simply malicious code. It was the assumption that useful volunteers are necessarily benign, release archives match reviewed source, tiny projects will somehow sustain themselves and somebody else is checking the foundations.

The operation failed because an engineer noticed a small delay and kept investigating.

That is a reassuring ending, but a poor security strategy.

The lesson of XZ is not that open source cannot be trusted. It is that trust must be supported by evidence, repeatable processes and enough people to notice when something ordinary begins behaving strangely.

Sources

Reference video

Veritasium, “The Internet Was Weeks Away From Disaster and No One Knew”, February 2026