In March 2024, Andres Freund, a Microsoft engineer and PostgreSQL developer, noticed something odd. SSH logins were taking 500ms instead of the usual 100ms. That’s it. A half-second delay.
That 500ms delay led to the discovery of CVE-2024-3094, a CVSS 10.0 backdoor that could have compromised hundreds of millions of servers running OpenSSH.
The backdoor was the result of a multi-year social engineering campaign targeting XZ Utils—a data compression library bundled with virtually every major Linux distribution. The campaign exploited maintainer burnout in what turned out to be one of the most patient and sophisticated supply chain attacks ever documented.
This article walks through how the attack worked, why the social engineering succeeded, and what you can do about it. Foundation support and paid maintainer models aren’t charity—they’re structural solutions to a systemic security problem.
For broader context on software supply chain security, this attack is a case study in how human vulnerabilities become technical vulnerabilities.
What Is the XZ Utils Backdoor and How Was It Discovered?
CVE-2024-3094 is a backdoor in XZ Utils versions 5.6.0 and 5.6.1. It enabled remote code execution via OpenSSH authentication bypass. If you had a specific Ed448 private key you could execute arbitrary code on affected systems.
Freund’s discovery came from investigating that 500ms SSH delay. He ran Valgrind—a memory debugging tool—and it threw errors on the affected system. He traced it to liblzma, the compression library provided by XZ Utils.
On 28 March 2024, Freund reported his findings to the Openwall Project security mailing list. Within 24 hours, Linux distributions—Red Hat, SUSE, Debian—reverted affected packages. CISA issued an advisory recommending immediate rollback.
The backdoor had been packaged in development versions of several distributions: Fedora Linux 40 beta, Fedora Rawhide, Debian unstable/testing, Kali Linux, and Arch Linux. It was discovered before reaching stable LTS releases. The timing was deliberate—aligned with Fedora Rawhide and RHEL 9.4 release schedules in April 2024.
Alex Stamos noted that “this could have been the most widespread and effective backdoor ever planted in any software product.” Had it remained undetected, it would have “given its creators a master key to any of the hundreds of millions of computers around the world that run SSH.”
How Did the Technical Backdoor Work?
The attack exploited a dependency chain most people wouldn’t think about. Linux distributions patch OpenSSH to use libsystemd for service notifications. Libsystemd loads liblzma for compression. This created a path from a compression library to SSH authentication.
The malicious code was hidden in release tarballs, not the Git repository. This is important. Code review of the repository wouldn’t have caught it. The backdoor lived in modified build scripts (build-to-host.m4) and obfuscated binary test files (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma).
The Dependency Chain: OpenSSH to liblzma
OpenSSH doesn’t normally load liblzma. But a third-party patch used by several distributions causes it to load libsystemd, which then loads liblzma. This patch supports sd_notify—the function systemd uses for service start notifications.
Why does this matter? Because it created an attack surface no one was watching.
Multi-Stage Payload Delivery
The backdoor activated in two stages. Stage 1 extracted malicious scripts from test files during the configure step. Stage 2 injected backdoor code into compiled object files during the make step, using RC4 decryption and head/tr obfuscation.
The modified build-to-host.m4 file existed only in the release tarball uploaded to GitHub. It was never in the git repository. Anyone reviewing the source code would see clean commits while the distributed software contained the backdoor.
IFUNC Function Hijacking
The attack leveraged glibc‘s IFUNC (indirect function) resolver mechanism. IFUNC is a legitimate feature that allows runtime selection of optimised function implementations based on hardware capabilities—think CPU-specific optimisations for performance.
In June 2023, Jia Tan introduced IFUNC resolvers (crc32_resolve, crc64_resolve) through seemingly legitimate commits. These resolvers were exploited to replace OpenSSH’s RSA_public_decrypt function at runtime.
Because IFUNC runs early in process initialisation, it’s particularly stealthy. The code hijacks RSA_public_decrypt, allowing an attacker with a specific Ed448 private key to execute arbitrary code.
Build system checks ensured the backdoor only activated on x86-64 systems using glibc, GCC, and dpkg or rpm package managers. This specifically targeted Debian and Fedora derivatives.
For context on preventing this type of build compromise, SLSA build integrity frameworks address build integrity at the infrastructure level.
What Was the Multi-Year Social Engineering Campaign?
The technical backdoor was sophisticated. The social engineering campaign that enabled it was patient. Extremely patient.
Phase 1: Entry and Trust Building (2021-2022)
Jia Tan (pseudonym JiaT75) made their first contribution to XZ Utils on 29 October 2021—a patch proposal for an .editorconfig file. Small. Legitimate. The kind of contribution that builds trust.
Their first authored commit came on 21 January 2022. Over the following months, Jia Tan contributed code reviews, translations, CI/CD maintenance, and infrastructure improvements. All legitimate work. All designed to build credibility.
Phase 2: Pressure and Position Acquisition (2022-2023)
In May-June 2022, sock puppet accounts appeared on the xz-devel mailing list pressuring the maintainer to add co-maintainers. They cited slow release cycles and unresponsive maintenance.
These accounts—Jigar Kumar, krygorin4545, misoeater91, Dennis Ens—had minimal GitHub activity and suspicious creation dates, all post-2021. The pressure campaign was coordinated.
The primary maintainer was a single volunteer maintaining infrastructure used by virtually every Linux distribution. He was burned out and struggling to keep up with maintenance demands. Adding a co-maintainer was a rational response to real resource constraints.
On 12 December 2022, Jia Tan created the GitHub organisation and repository for XZ Utils. They set their email as the default project contact. They made their first release as a maintainer on 13 December 2022.
The migration from SourceForge to GitHub gave Jia Tan organisational control.
Phase 3: Backdoor Insertion and Distribution (2024)
By 2024, Jia Tan had sufficient privileges to create and distribute release tarballs containing code that didn’t exist in the public Git repository.
The first backdoor commit was made on 22 January 2024. XZ 5.6.0 was released on 24 February 2024. A commit on 26 February sabotaged the Landlock security feature. XZ 5.6.1 was released on 9 March 2024.
The campaign spanned three years. 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.
Why Are Open Source Maintainers Vulnerable to Takeover?
XZ Utils was appealing to attackers because it was a low-traffic repository managed by a single developer with a small community—around 10 active members on the project’s IRC channel. This “bus factor” of one created a systemic vulnerability.
The maintainer was experiencing burnout, not negligence. Maintainer burnout is a structural problem—open-source infrastructure depends on unpaid labour. Maintainers of important software sometimes work 22-hour days for free. When maintainers burn out, supply chain attacks become easy.
The sock puppet pressure campaign succeeded precisely because the maintainer was already overwhelmed. Adding a co-maintainer was a rational response. The social engineering exploited real resource constraints.
Following the incident, OpenSSF and OpenJS Foundation warned that the XZ Utils backdoor “may not be an isolated incident.” They advised maintainers to watch for “friendly yet aggressive and persistent pursuit” by unknown community members seeking maintainer status. Similar social engineering attempts had targeted JavaScript projects.
The EU Cyber Resilience Act (CRA), coming into force by December 2027, will require supply chain security assurances. Companies will have to ensure their entire open-source supply chain complies with CRA regulations. At least 50% of foundations say they have insufficient financial support to ensure CRA compliance.
Security researcher Dave Aitel has suggested the attack fits patterns attributable to APT29 (Cozy Bear), believed to be working on behalf of Russia’s Foreign Intelligence Service. The multi-year patience, operational security, and sophistication align with nation-state tradecraft, though attribution remains unconfirmed.
For deeper exploration of how burnout creates attack surfaces, foundation support reduces security risk through economic and governance solutions.
How Do Foundation Support and Paid Maintainers Reduce Risk?
Paying to avoid the liability caused by unstable and insecure software just makes financial sense. It helps companies safeguard the stability and security that keeps their products running.
Foundation governance structures—Apache Software Foundation, Eclipse Foundation, CNCF—provide multi-party code review, release management processes, and succession planning. These eliminate single-maintainer risk.
Foundation governance would have provided the multi-party oversight needed to disrupt this attack. No single maintainer should have unilateral authority to push release artefacts.
The most reliable way to ensure CRA compliance is to collaborate with open-source foundations that take on the work of certifying packages. Open-source foundations are the greatest ally in ensuring companies comply with EU law.
The contrast is stark. The XZ attack exploited a lone, burned-out volunteer with sole control over release distribution for infrastructure used by hundreds of millions of systems. Foundation governance would have disrupted this campaign at multiple points.
For comprehensive coverage of how foundation support reduces open source security risk and paid maintainer programmes work, see the dedicated analysis.
What Should Organisations Do to Assess Maintainer Health in Their Dependencies?
Never assume that code from trusted maintainers or official releases is immune to tampering. Verifying source tarballs against repository history and maintaining reproducible builds can help detect unexpected changes.
Evaluate dependency maintainer health as part of vendor due diligence. Check contributor count (bus factor), commit frequency, issue response times, and whether the project has foundation backing or corporate sponsorship.
Implement dependency selection criteria that incorporate maintainer sustainability alongside technical fitness. A technically excellent library maintained by a single burned-out volunteer is a liability, not an asset.
Monitor for social engineering indicators. Watch for sudden new co-maintainers, mailing list pressure campaigns, infrastructure migrations, and discrepancies between Git repositories and release tarballs.
Sometimes the first sign of compromise isn’t an alert but a “why is this slow?” moment. Monitor performance anomalies. Stay on top of advisories—when CISA or your distribution releases an advisory, act immediately.
Establish organisational open-source sponsorship programmes targeting the dependencies in your supply chain. Direct funding, developer time contributions, or foundation membership all reduce the maintainer burnout that created the XZ vulnerability.
Use SBOM (Software Bill of Materials) practices to maintain visibility into your transitive dependency tree, identifying single-maintainer projects before they become attack vectors.
Had any downstream consumer invested in XZ Utils’ maintainer health, the social engineering campaign would have been far more difficult to execute.
For implementing SLSA build integrity frameworks that address tarball tampering and release verification, see the comprehensive SLSA guide.
How Can Organisations Support Sustainable Open Source?
Direct financial sponsorship of dependencies through platforms like GitHub Sponsors, Open Collective, or thanks.dev reduces the maintainer burnout that enabled the XZ backdoor. If you pay maintainers at least $2000 per full-time equivalent developer you employ per year, you’re eligible to become a member of the Open Source Pledge.
Contributing developer time to open-source projects—bug fixes, code reviews, documentation—provides capacity without requiring the maintainer to accept sole responsibility.
Foundation membership (OpenSSF, Apache, CNCF) supports governance infrastructure that prevents single-point-of-failure maintainer situations across the ecosystem. Your company should pay the foundations relevant to your ecosystem.
Advocacy for regulatory frameworks like the EU Cyber Resilience Act creates market incentives for supply chain security investment, making sustainability a business requirement rather than charity.
Internal open-source programme offices (OSPOs) can systematically audit dependency health, allocate sponsorship budgets, and track the security outcomes of sustainability investments.
The cost-benefit analysis is clear. The potential impact of a compromised dependency reaching production—hundreds of millions of servers in the XZ case—vastly exceeds the cost of maintainer support programmes. Being a forward-thinking open-source pioneer that pays maintainers reflects positively on your company’s brand.
For comprehensive maintainer sustainability strategies and implementation guidance, see dedicated coverage. For complete software supply chain security strategies incorporating maintainer health alongside technical controls, see the broader framework.
FAQ Section
What Linux distributions were affected by the XZ Utils backdoor?
The backdoor was present in XZ Utils versions 5.6.0 and 5.6.1. Rolling-release and development distributions were affected—Debian Sid (unstable), Fedora Rawhide, openSUSE Tumbleweed, Kali Linux, and Arch Linux. Stable LTS releases (Debian stable, Ubuntu LTS, RHEL) hadn’t incorporated the compromised versions before discovery. The attack was timed for Fedora Rawhide and RHEL 9.4’s April 2024 release schedule.
How did one person discover the XZ backdoor before it reached production systems?
Andres Freund was benchmarking PostgreSQL on Debian Sid when he noticed SSH logins taking 500ms instead of the normal 100ms. He investigated, found Valgrind errors pointing to liblzma, and traced the issue to malicious code in the XZ Utils release tarballs. He reported it to the Openwall Project security mailing list on 28 March 2024.
Why was the malicious code in the release tarballs but not the Git repository?
Release tarballs are compiled source archives distributed separately from Git repositories. They contain generated build scripts and test files that don’t exist in the version-controlled source. Jia Tan hid the malicious code in modified build-to-host.m4 and obfuscated binary test files within the tarball, ensuring standard code review of the Git repository wouldn’t detect it.
What is IFUNC and how was it exploited in the XZ attack?
IFUNC (indirect function) is a glibc feature that allows runtime selection of optimised function implementations based on hardware capabilities. In June 2023, Jia Tan introduced IFUNC resolvers (crc32_resolve, crc64_resolve) through seemingly legitimate commits. These resolvers were exploited to replace OpenSSH’s RSA_public_decrypt function at runtime, enabling the SSH authentication bypass without modifying OpenSSH source code.
Could the XZ backdoor have been detected by automated security scanning?
Standard static analysis and vulnerability scanning tools wouldn’t have caught this backdoor. The malicious code existed only in release tarballs (not Git), was obfuscated across multiple binary test files, and used legitimate build system mechanisms. Detection required observing runtime behaviour anomalies—the 500ms SSH delay. This highlights the limitations of automated security approaches for sophisticated supply chain attacks.
What is the connection between the XZ backdoor and nation-state actors?
Security researcher Dave Aitel has suggested the multi-year patience, operational security, and sophistication of the campaign align with APT29 (Cozy Bear) tradecraft, associated with Russia’s Foreign Intelligence Service (SVR). While attribution remains unconfirmed, the resources and time invested in the campaign exceed what’s typical for individual or criminal actors.
How does the XZ attack compare to the SolarWinds supply chain attack?
Both are supply chain attacks but use different methodologies. SolarWinds SUNBURST involved nation-state actors compromising a commercial vendor’s build system to distribute malware to 18,000+ organisations. The XZ attack used social engineering to take over an open-source project from the inside over multiple years. SolarWinds targeted a commercial product; XZ targeted volunteer-maintained infrastructure. Both demonstrate supply chain attack diversity.
Were Docker images affected by the XZ Utils backdoor?
Yes. Debian development images on Docker Hub contained the backdoored XZ Utils versions and weren’t immediately remediated. In August 2025, Binarly researchers discovered affected images remained available. Organisations using Debian Sid-based Docker images for development or CI/CD pipelines should audit their image histories and rebuild from verified base images.
What is the “bus factor” and why does it matter for supply chain security?
The “bus factor” refers to how many maintainers would need to be unavailable (hit by a bus, metaphorically) before a project becomes unmaintainable. XZ Utils had a bus factor of one—a single volunteer maintainer. This made it vulnerable to social engineering because there was no second reviewer, no formal release process, and no institutional oversight. Projects with higher bus factors are structurally more resistant to hostile takeover.
What regulatory changes are being driven by incidents like the XZ backdoor?
The EU Cyber Resilience Act (CRA), scheduled for enforcement by December 2027, will require software supply chain security assurances across the European market. This creates legal and compliance incentives for organisations to invest in dependency health, maintainer support, and supply chain verification. Similar regulatory discussions are occurring in the US and other jurisdictions following high-profile supply chain incidents.
