how it happened
- who"contributor"two years of trust building
- the targetmaintainer accesshanded over gradually
- thenversions 5.6.0, 5.6.1targeted SSH logins
- how it stoppedcaughta slow login, noticed
what everyone assumed
The comfortable belief about open source is that many eyes make code safe, and that a library shipped inside nearly every Linux distribution has been watched closely enough to trust. It is a reasonable belief, because most of the time it holds. What it quietly assumes is that the people contributing are who they present themselves to be, and that a maintainer offered steady help has no reason to suspect the help is the attack.
what happened
The pressure on the project was ordinary and visible: one overstretched maintainer, public messages pushing for the newer contributor to be given more authority, a slow handover that looked like succession planning. Across roughly two years the contributor built credibility commit by commit, then used that standing to introduce a backdoor into liblzma, hidden inside files disguised as test data and assembled only during the build. The malicious code was written to interfere with SSH authentication on systems that linked the library, and it shipped in versions 5.6.0 and 5.6.1. The maintainer who had been worn down and won over was the target of the operation, not its author.
step by step
- one overstretched maintainerPublic pressure to hand over authority.
- a contributor builds trust for two yearsCommit by commit.the assumption breaks here
- a backdoor hidden in test filesVersions 5.6.0 and 5.6.1, aimed at SSH authentication.
- 29 March 2024half a second of latency gives it awayAndres Freund finds CVE-2024-3094, days from stable releases.
how it surfaced
On March 29, 2024, a Microsoft engineer named Andres Freund noticed SSH logins on a test machine were a little slow and using more CPU than they should. He followed the anomaly into the compression library and found the backdoor, catalogued as CVE-2024-3094 and scored the maximum 10. The code was days from reaching stable, widely-shipped releases. It was found because one person chased half a second of latency he could have ignored.
Open source is watched by people, and people can be befriended, exhausted, and outlasted; a library being everywhere does not mean anyone is positioned to see a patient insider who arrived looking like a volunteer.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersThey hide a backdoor in an update that is days from wide release.what it costs youIt is caught by luck, because one person noticed a login was half a second slow.
- or it goes like thisit happenedSolarWinds / Sunburst, 2020howA genuine, signed update from a certified vendor carries a backdoor.what leavesa quiet way into your networkwho ends up with ita state intelligence service
- or it goes like thisit happenedtj-actions/changed-files, 2025howA build helper everyone uses is hijacked and its versions repointed.what leavessecret keys, printed into build logswho ends up with itanyone reading public logs
sources
your turn
what you can do about it
this week
Look at whether you know which open-source packages your products actually depend on, all the way down, and whether you would learn about a compromised one from anything other than the news.
Your software is built on open-source components you did not write and do not staff, pulled in through layers of dependencies most teams have never fully listed. The assumption to retire is that popularity is the same as oversight. The XZ backdoor was stopped by luck and one curious engineer, which is a thin layer to keep building on.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →