Updated 23 August 2026 — this article was rewritten with primary sources added and unsupported claims removed.
The xz backdoor was found because a Microsoft engineer thought his SSH logins were about half a second slower than they should be. Andres Freund chased the latency, found it in liblzma, and posted what he had to the oss-security mailing list on 29 March 2024 under the flat subject line “backdoor in upstream xz/liblzma leading to ssh server compromise” (oss-security). The vulnerability that followed, CVE-2024-3094, carries a CVSS 3.1 base score of 10.0 — the maximum — assigned by Red Hat as the responsible CNA (National Vulnerability Database).
Every technical account of that incident is accurate and slightly beside the point. The backdoor was clever, but the cleverness was not what nearly worked. What nearly worked was a person spending years being helpful.
The resource that was attacked was patience
The account assembled by Datadog’s security researchers describes a contributor who arrived, submitted useful patches, stayed, and was gradually handed responsibility over a period measured in years rather than weeks — while the original maintainer, under public pressure about the pace of releases, accepted the help (Datadog Security Labs). Nothing in that sequence looks like an attack while it is happening. It looks like the thing every under-resourced project is desperate for.
That is what makes it structurally different from a vulnerability. A buffer overflow is a mistake in code, and code can be re-read. This was an exploit against the review process itself: against the fact that a maintainer who has been alone for a decade will eventually accept a co-maintainer, and against the fact that nobody downstream was checking whether the release tarball matched the repository. The malicious code was not in the git tree in any obvious form. It was in the shipped artefact.
The uncomfortable implication is that the defences most organisations had bought would not have helped. Scanning the source would have found nothing. Checking the signature would have confirmed that the artefact really was signed by the project’s maintainer, which it was. The compromise was upstream of everything a consumer normally verifies.
How it was hidden
The construction matters because it explains why ordinary review missed it. The malicious logic did not sit in the project’s source as readable C. It was staged across files that almost nobody audits: test fixtures — binary blobs that are meant to look like meaningless data — and the build scripts that run when a package is compiled from a release tarball rather than from a git checkout. Those two hiding places are complementary. A reviewer reading the repository sees no hostile code. A distribution packager building from the official tarball gets it anyway, because the tarball’s build machinery differs from what is in version control.
From there the payload reached its target through a dependency chain nobody had chosen deliberately. liblzma is compression, not cryptography, and it has no business anywhere near authentication. But on several major distributions sshd links against libsystemd for service notification, and libsystemd pulls in liblzma. The backdoor used that indirect route to hook into the SSH daemon’s authentication path — as Datadog’s write-up traces in detail. The relevant lesson for anyone maintaining a dependency inventory is that the blast radius of a compression library was determined by a packaging decision three layers away from either project.
It also went to some trouble to stay quiet. The activation logic checked its environment and did nothing under conditions that looked like analysis, which is why the performance anomaly Freund noticed was very nearly the only externally visible symptom. Half a second of latency was the entire tell.
What actually changed afterwards
The most durable response was unglamorous: distributions and upstreams have moved, unevenly, toward building from version control rather than from maintainer-generated tarballs, and toward making the two verifiably identical. That is the same reproducible-builds problem the packaging ecosystems keep arriving at from different directions — if the artefact can be rebuilt byte-for-byte from the public source, the hiding place used here closes.
The second change is social and harder to measure. Handing over maintainership is now treated by some projects as a security event with a process attached, rather than a relief. That is a reasonable adaptation, though it carries an obvious cost: the projects most in need of new maintainers are precisely the ones now most nervous about accepting them. The attack made an already-hostile recruitment problem worse, which may prove to be its most expensive consequence.
What has not changed is the underlying arithmetic. The number of single-maintainer projects sitting under production systems is roughly what it was, and the mechanism that nearly succeeded remains available to anyone patient enough to use it.
Why this is an economics problem wearing a security costume
The uncomfortable follow-on question is how many other projects sit in the same position: one exhausted maintainer, a decade of accumulated trust, and a dependency graph beneath half the internet. The Linux Foundation’s Census III work, done with Harvard’s Laboratory for Innovation Science, was built to answer exactly that by measuring which free software is actually running in production across thousands of companies, and it identifies projects staffed by too few developers as a live risk rather than a theoretical one (Linux Foundation).
Framed that way, maintainer burnout stops being a wellbeing topic and becomes a threat model. A maintainer with a full inbox is a maintainer whose security reports wait. A maintainer who has decided to step back is a maintainer looking for someone to hand the keys to. Neither of those states is visible in a dependency scan, and both are exactly the conditions the xz operation needed.
The funding responses that followed — government-backed investment in critical infrastructure libraries, foundation programmes paying maintainers directly — are usually filed under sustainability. They are more defensible as security spending, because they change the variable the attacker was actually exploiting.
What to keep on hand
These are the resources worth knowing about, and what each is actually for. None of them would have caught xz on its own; together they narrow the surface.
- Andres Freund’s original oss-security disclosure — the primary account, written before any narrative formed around it. Read this rather than a summary if you want to understand what detection actually looked like.
- NVD entry for CVE-2024-3094 — the authoritative record of severity, affected versions and vector. Note the score comes from Red Hat as CNA, which is normal and worth knowing when you cite it.
- OpenSSF Scorecard — automated checks across a project’s security practices, source and build process. Use it to triage which of your dependencies deserve a human look, not as a pass/fail gate.
- OpenSSF Best Practices Badge — self-assessed but specific. A project that has worked through it has at least been asked the right questions about reporting channels and release process.
- Harvard’s summary of Census III lessons — the research read of which components are most depended upon and where concentration risk sits. Useful for deciding where to spend attention first.
- Sovereign Tech Fund — public investment in the base technologies other software is built on. The clearest existing model for treating maintenance as infrastructure rather than charity.
- OpenSSF’s Scorecard project page — the checks and their rationale, if you want to know what a given score is measuring before you act on it.
The registries have been building machinery aimed at part of this: trusted publishing ties an artefact to the CI run that produced it. It would not have stopped this attack, because the malicious commit entered upstream of the build and the provenance record would have been perfectly valid. The closed-source equivalent of the same limitation shows up whenever a vendor’s account of its own binary is the only available evidence.
The check almost nobody runs
There is one exercise that would have surfaced this class of attack, and it takes an afternoon rather than a budget. Pick the ten dependencies your production systems would be worst affected by. For each, answer three questions from public information: how many people have merged a commit in the last year, whether the artefact you install is built from the repository or uploaded separately by a maintainer, and whether anyone has joined the maintainer list recently.
None of those questions requires tooling. All three are visible in a repository’s history and a registry’s metadata, and together they identify the projects where a single person’s judgement — or a single person’s exhaustion — is the control you are relying on. Scorecard can narrow the list for you, but the reading is the part that matters, and it is the part that gets skipped because it does not produce a number to put in a report.
Back to the half second
The detail that should stay with anyone reading this is not the ingenuity of the payload. It is that the backdoor was caught by one person, off the clock, following an anomaly nobody had asked him to investigate — and that had he been slightly less curious, a compromised sshd would have shipped into stable distributions.
That is not a system working. That is a system getting lucky, once, in public. The practical response for anyone consuming open source is narrower than the discourse suggests: know which of your dependencies have exactly one maintainer, prefer artefacts you can rebuild from source over ones you can only download, and treat a project’s sudden acquisition of an enthusiastic new co-maintainer as a fact about your risk rather than a piece of good news.
