Résumé
The xz backdoor, disclosed on 29 March 2024, is the closest the open-source world has come to a catastrophe, and it was stopped by luck. Over nearly three years, an attacker operating as a friendly, productive contributor named "Jia Tan" patiently earned the trust of the lone, burnt-out maintainer of xz Utils, a compression library that is a quiet dependency of almost every Linux system. Handed co-maintainer rights, the attacker slipped an extraordinarily well-hidden backdoor into the xz release tarballs (versions 5.6.0 and 5.6.1) that, on affected systems, would let anyone holding a secret key bypass SSH authentication and run commands as root. It was caught days before it reached the stable releases of major Linux distributions by a Microsoft engineer who noticed his SSH logins were running about half a second slower than they should. Had he not, it would have been a backdoor into a huge fraction of the world's servers. It is the defining lesson in open-source maintainer burnout and how deep a patient supply-chain attack can reach.
How it happened
The attack was social engineering played over years, not a clever exploit. xz Utils was maintained by one volunteer, Lasse Collin, who was overwhelmed and, it later emerged, being pressured to hand the project off. In 2021 a contributor calling themselves "Jia Tan" appeared and began submitting patches. Meanwhile a cluster of sockpuppet accounts, names like "Jigar Kumar" and "Dennis Ens" with no presence anywhere else, bombarded the mailing list demanding a new maintainer ("Patches spend years on this mailing list," one complained; "the current maintainer lost interest"). The pressure worked. By the end of 2022 Jia Tan was a co-maintainer merging their own commits, and in early 2024 they cut the poisoned releases, 5.6.0 and 5.6.1. It was a years-long con to become the maintainer.
The backdoor itself was a masterpiece of concealment, and crucially it was not in the git source that people review. It hid in the release tarball's build machinery: a binary "test file" plus an obfuscated build step that only assembled the payload under specific conditions (building a Debian or RPM package). There is a reason xz was even in reach of sshd: OpenSSH does not use liblzma, but several Linux distributions patch sshd to integrate with systemd, which pulls in libsystemd, which depends on liblzma. When sshd loaded the backdoored library, the malware used a glibc feature called an IFUNC resolver to silently hook OpenSSL's RSA_public_decrypt function. From then on, a crafted SSH login carrying a payload that decrypted under a hard-coded key and matched the attacker's Ed448 signature would run its embedded command as root, bypassing authentication entirely. Only the attacker's private key could trigger it, and anyone reviewing the source code would have seen nothing wrong, because the malice lived in the build, not the code.
How it was caught
By a fluke of diligence. Andres Freund, a Microsoft engineer working on the PostgreSQL database, was running benchmarks and noticed that sshd was burning unusual amounts of CPU and that logins were about 500 milliseconds slower than expected. Rather than shrug, he investigated, traced the delay into liblzma, and realised he was looking at a deliberate backdoor. He disclosed it on 29 March 2024. By then the poisoned versions had reached the cutting-edge, testing branches of Debian, Fedora, openSUSE, and Kali, but had not yet flowed into the stable releases that run production servers, even as the attacker was emailing distribution maintainers to hurry the new version into the next Ubuntu and Fedora. The world was days, not months, from disaster.
Why xz still matters
xz exposed the structural fragility under modern software: critical global infrastructure maintained by a single, unpaid, exhausted volunteer, who trusted a helpful stranger because help is exactly what an overworked maintainer needs. The attack defeated every normal control. The source was clean. The contributor was "trusted." The malware was in the build, not the code. It is the social engineering of the supply chain itself: not stealing a token like the event-stream takeover, but becoming the person everyone trusts. The lessons are uncomfortable: fund and staff the critical open-source projects everyone depends on, build from reviewed source rather than opaque tarballs, scrutinise maintainer handoffs, and reduce attack surface (a compression library should never have been in the path of the SSH daemon). It nearly proved that "many eyes make bugs shallow" fails completely when there are almost no eyes.
Comment le corriger
- Downgrade xz and liblzma to a known-good version (the 5.4.x line) anywhere that pulled 5.6.0 or 5.6.1, and confirm sshd is no longer linked against the backdoored library.
- Treat any exposed system as suspect: rotate SSH host keys and credentials and hunt for unauthorised access, since the backdoor allowed authentication bypass.
- Rebuild from trusted, verified source rather than the poisoned release tarballs, and confirm the build matches the reviewed code.
Comment l’éviter
- Prefer reproducible builds and build from reviewed source, not from release tarballs whose build scripts no human reads; the backdoor lived precisely where review does not look.
- Reduce attack surface and dependency depth: question why security-critical services link against general-purpose libraries, and minimise what is loaded into something as sensitive as sshd.
- Scrutinise sudden maintainer changes and handoffs on critical dependencies, and support the projects you rely on so a lone, burnt-out maintainer is not the only thing between you and a backdoor.
- Invest in the ability to notice when something is subtly off; this backdoor was caught by a half-second performance anomaly, nothing more.
Références
- https://www.openwall.com/lists/oss-security/2024/03/29/4
- https://research.swtch.com/xz-timeline
- https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know
- https://securitylabs.datadoghq.com/articles/xz-backdoor-cve-2024-3094/
- https://en.wikipedia.org/wiki/XZ_Utils_backdoor
Vulnérabilités liées
Tout Supply chain →- CRITICALGHSA-93qj-5q5v-3c2h
Trojanized pantheon-agents 0.6.1 and 0.6.2 on PyPI ship a credential stealer (supply-chain account compromise)
- CRITICALNPM-REDHAT-MIASMA-2026
In June 2026 the npm supply-chain worm finally produced something genuinely new and frightening: malicious packages that were signed and carried valid build provenance. Attackers used a compromised GitHub account inside Red Hat's own organisation to publish trojanised versions of 31 packages in the @redhat-cloud-services namespace through Red Hat's legitimate CI pipeline, so the poisoned releases arrived with authentic attestations proving they were built by the real build system. The payload, nicknamed Miasma, was a lightly re-skinned copy of Mini Shai-Hulud, a worm that a group called TeamPCP had open-sourced for anyone to reuse weeks earlier. No Red Hat customers were harmed, because Red Hat strips install scripts before deployment, but the permanent lesson is uncomfortable: a signature proves where a package was built, not that the build was clean.
- CRITICALNPM-AXIOS-2026
On 31 March 2026 the single most widely used HTTP client in the JavaScript world was turned into malware for about three hours. Axios carries well over 100 million weekly downloads and sits as a transitive dependency underneath a huge share of the npm ecosystem, so when a North Korea-nexus actor took over the maintainer's account and published two booby-trapped versions, the blast radius was enormous even though the bad versions were live only for one early-morning window. The poisoned releases pulled in a hidden dependency that ran on install and dropped a cross-platform remote access trojan onto developer machines and CI runners. It is the case study in why a few hours of a popular package being compromised is still a global incident, and in why a maintainer's own laptop is now a nation-state target.
- HIGHSC-NOTEPADPP-CHRYSALIS-2025
In 2025, a Chinese state-linked espionage group hijacked the update channel of Notepad++, one of the most widely installed Windows text editors, to plant a custom backdoor on a handful of carefully chosen targets. The attackers never touched Notepad++'s source code or its signing keys. Instead they compromised the third-party shared-hosting server that delivered updates, and abused the fact that the WinGUp updater shipped without any integrity check on what it downloaded (tracked as CVE-2025-15556). For machines on their target list, WinGUp was silently redirected to attacker-controlled servers that served a trojanized installer; everyone else kept receiving the genuine update. The campaign ran from roughly June to December 2025 and was only made public in February 2026 by Rapid7, with Kaspersky and Broadcom/Symantec corroborating it independently.
- HIGHSC-ESCAN-RELOAD-2026
On or around January 20, 2026, attackers who had broken into a regional update server for eScan, the antivirus product made by India's MicroWorld Technologies, pushed a trojanized Reload.exe through the legitimate update channel during a window of roughly two hours. The security software itself became the delivery vehicle for malware. The malicious binary carried eScan's code-signing identity, but its signature was actually invalid; it ran anyway because the updater trusted the channel rather than rigorously validating the signature. Once on a host, the malware rewrote the Windows HOSTS file to cut eScan off from its own update servers, blinded script scanning, and reached out to takedown-resistant command-and-control hosted on blockchain naming systems. Morphisec disclosed the campaign, with Kaspersky and Darktrace corroborating it independently.
- CRITICALNPM-SHAI-HULUD-2-2025
Shai-Hulud is the nightmare the npm ecosystem had long feared: a self-replicating worm. First seen in September 2025 and back in a more aggressive wave around 21-24 November 2025 ("The Second Coming"), it does not just poison one package and wait. When its malware runs in a developer's environment, it harvests every secret it can find, npm tokens, GitHub tokens, cloud keys, then uses those stolen npm tokens to automatically publish itself into other packages the victim maintains, spreading from maintainer to maintainer on its own. The second wave hit more than 25,000 GitHub repositories across roughly 500 compromised accounts, leaked the stolen secrets into public repos, and, if it failed to steal credentials, tried to wipe the victim's home directory. It is the moment supply-chain malware learned to propagate like a biological infection.