The xz Backdoor Wasn't a Bug. It Was a Burned-Out Maintainer.

In June 2022, a maintainer named Lasse Collin posted to the xz-utils mailing list. He wasn't announcing a release. He was explaining why there hadn't been one: "my ability to care has been fairly limited mostly due to longterm mental health issues." He was the sole maintainer of a compression library buried inside nearly every Linux distribution on Earth, and he was saying, in public, that he was drowning.

Within weeks, accounts with names like "Jigar Kumar" and "Jia Tan" started showing up in the mailing list, pushing — politely, persistently — for Collin to bring on a co-maintainer. They kept at it for almost two years. In February 2024, Jia Tan shipped xz version 5.6.0. It contained a backdoor engineered to intercept SSH authentication on affected systems — one of the most sophisticated supply-chain attacks ever found in open-source software, caught only because a Microsoft engineer named Andres Freund noticed his SSH logins were running half a second slower than they should.

Every retrospective on the xz backdoor calls it a supply-chain security incident. Add better SBOM tooling, more dependency scanning, stricter commit review, and this doesn't happen again — that's the consensus fix. It's wrong, or at least it's incomplete. What actually happened is that an attacker identified a maintainer who had told the internet he was burned out, and spent two years exploiting that burnout with the patience of someone running a long con. The vulnerability wasn't in the code. It was in the fact that one person, unpaid, was the only thing standing between a billion-dollar ecosystem and whoever decided to be patient about it.

Open source runs on unpaid labor at a scale nobody accounts for

Here's the number that should reframe how you think about every npm install you've ever run: 60% of open-source maintainers work entirely unpaid, according to Tidelift's 2024 State of the Open Source Maintainer survey of 437 maintainers. Of those, 44% cite burnout specifically as their reason for walking away from a project — and 60% overall say they've quit or seriously considered it, up two points year over year.

Harvard Business School put a number on what that unpaid labor is worth: $8.8 trillion in demand-side value generated globally by open-source software, with 96% of that value produced by just 5% of contributing developers. The Linux Foundation's 2024 Census III found something structurally identical from a different angle — 64% of the top 500 open-source projects are maintained by four or fewer people, and half of the highest-use projects depend on just 10% of their contributors. Socket.dev's research puts a rough headcount on the whole exposed surface: roughly 10,000 people worldwide are effectively sustaining the critical infrastructure that trillion-dollar companies build on top of, for free.

That's not a talent pipeline. That's a small number of unpaid people holding up a supply chain, and every one of them is a potential Lasse Collin — reachable, human, and exhaustible.

Burnout is a documented attack vector, not a mood

The xz-utils case isn't a one-off. It's a pattern with a name in the security community now: burnout-as-attack-surface. Filippo Valsorda's independent survey of confirmed open-source supply-chain compromises in 2024–2025 counted roughly 20 incidents, and in the aftermath of xz, 66% of surveyed maintainers reported reduced trust in unsolicited pull requests, while 37% said they now scrutinize potential co-maintainers more carefully. The community learned the lesson after the fact. The attackers had already built it into their playbook.

You can see the exhaustion pattern surfacing in public even where there's no backdoor at the end of it. Hector Martin, who led the Asahi Linux project bringing Linux support to Apple Silicon, resigned in February 2025 after what he described as years of harassment: "No matter how much we did... people always wanted more." In November 2025, the maintainers of Kubernetes' Ingress-NGINX controller — one of the most widely deployed pieces of infrastructure on the internet — announced retirement, citing "only one or two people doing development work, on their own time, after work hours and weekends." No malicious actor exploited either of those. They didn't need to. The maintainers exploited themselves first, by staying too long past the point of sustainability.

The industry's fix treats the symptom, not the exposure

In September 2025, OpenSSF put out a joint statement that finally said the quiet part out loud: "Billion-dollar ecosystems cannot stand on foundations built of goodwill and unpaid weekends." Then in March 2026, Anthropic, AWS, Google, Microsoft, GitHub, and OpenAI jointly committed $12.5 million through OpenSSF and the Alpha-Omega project to shore up critical open-source security. Alpha-Omega had already deployed $5.8 million across 14 projects in 2025, funding security audits and hardening work.

$12.5 million sounds like real money until you set it against the $225 billion in annual labor value the Linux Foundation's research implies organizations are extracting from open-source contribution globally, or even against the $7.7 billion in direct organizational open-source investment it separately documented for 2024 — 86% of which is employee labor time, not maintainer paychecks. Only about 4,200 companies sponsor open-source projects directly, out of the roughly 300 million organizations that deploy open-source software somewhere in their stack. That's a participation rate of roughly 0.0014%.

And the money that does exist mostly funds audits, not people. It buys a security review of the code a burned-out maintainer already wrote, rather than paying that maintainer enough to not be burned out in the first place. Tidelift's data is direct about this: 81% of unpaid maintainers say they'd adopt static analysis, two-factor auth, and formal vulnerability disclosure processes — the exact hardening measures the audit money funds — if someone paid them to do it. The willingness was never the problem. The compensation was.

So actually — treat the maintainer as the security boundary

Every enterprise security team has a line item for dependency scanning, SBOM generation, and vulnerability management. Almost none of them has a line item for "does the maintainer of our fifth-order dependency have enough income that a stranger with two years of patience and a fake identity can't wear them down." That second question is the one xz answered for the entire industry, and the answer was no.

This is where I part ways with the standard security-engineering read on the incident. Scanning tools catch known bad code. They cannot catch a maintainer accepting help from someone who spent two years being helpful on purpose, because from the inside that decision looks like relief, not risk. The only thing that changes the calculus is removing the exhaustion that made relief so tempting in the first place — which means paying the person, not auditing the code they wrote while unpaid. If your organization's security tooling budget doesn't include direct maintainer compensation, you've bought insurance against the failure mode that already happened and skipped the one that's coming. Something similar is playing out in how teams treat AI code review as a productivity tool instead of a burnout risk — the exhaustion is the vulnerability, and nobody's line-iteming it.

The next backdoor in your dependency tree probably won't be caught by a scanner. It'll be caught, or not, by whether the person who maintains that dependency can afford to say no to a stranger's patience.