A package with one maintainer concentrates risk in one person: if they burn out, lose an account or hand over control to the wrong person, every project that depends on it is affected. The xz Utils case from 2024 is the best documented example. It does not mean single maintainer packages are unsafe, only that they deserve a plan.
What is the problem, exactly?
Open source packages are often maintained by one person or a very small group, unpaid, in spare time. That is how much useful software gets made. The risk comes from three situations: the maintainer stops, the account is taken over, or control is passed to someone who should not have it. Registries like npm and PyPI make it easy to depend on such packages and hard to see how thin the support behind them is.
We do not give a percentage of packages with one maintainer. We did not find a source we could verify and fetch.
What happened with xz?
Timeline from Russ Cox's published xz timeline and the original report:
- Lasse Collin, the long time maintainer of XZ Utils, made his last release as sole maintainer, version 5.4.1, on 11 January 2023.
- From 29 October 2021, a contributor named Jia Tan sent small patches. Jia Tan was added to the project's GitHub organization in October 2022, began merging commits directly on 30 December 2022 and tagged a first release on 18 March 2023.
- On 23 February 2024 hidden backdoor code was merged, concealed in binary test files. Version 5.6.0 was tagged on 24 February 2024 with a modified build script that added the backdoor when building packages. Version 5.6.1 followed.
- Andres Freund found the problem on 28 March 2024 and disclosed it publicly on 29 March. He noticed unusual SSH login behavior on Debian sid, including high CPU use and valgrind errors, and measured about 0.8 seconds for a failed login against a nonexistent user compared with about 0.3 seconds before. Red Hat assigned CVE-2024-3094.
- CISA's alert says versions 5.6.0 and 5.6.1 contain malicious code and recommends rolling back to a clean release such as 5.4.6 and checking systems for malicious activity.
Some write ups say the maintainer was under public pressure and cited limited capacity before control changed hands. We could only confirm that through secondary search summaries, so we do not rely on it. Who was behind the Jia Tan persona remains unconfirmed in what we reviewed.
What should we take from it?
First, discovery was lucky: a performance oddity noticed by an engineer, not a control. Second, the trust handoff was the weak point, not a code flaw. Third, the backdoor code was concealed in binary test files and activated by a modified build script in the release, which makes it hard to spot in a casual read of the source.
How can you assess exposure?
OpenSSF Scorecard runs automated checks on open source projects and gives each a score out of 10. Its Maintained check looks at whether a project is actively maintained, rated high risk, and its Contributors check looks for contributors from multiple organizations, rated low risk. Other checks cover branch protection, code review, signed releases and pinned dependencies. A low score is not proof of a problem, but it tells you where to look.
Combine that with your own questions: how many of your critical dependencies have one maintainer, how long since the last release, and is there a security policy?
What to do
- List your top 50 dependencies by blast radius, meaning what breaks if they are compromised.
- Check maintainer count, release recency and Scorecard results for each.
- For single maintainer packages that matter, record a fallback: a fork, a vendor, an alternative or a plan to fund.
- Pin versions and review updates to those packages before adopting them.
- Monitor for unexpected ownership or maintainer changes.
- Where you can, sponsor or contribute to critical projects you rely on.
- Rehearse removing or replacing one such dependency.
Safeguard's Gold registry and the free in browser scan at gold.safeguard.sh/scan (100 dependencies) can help you see what you depend on, including transitive packages.
Quick check
Is a single maintainer package unsafe?
Not by itself. It is a concentration of risk that needs a fallback plan.
Would a source code review have caught xz?
It was hidden in binary test files and enabled by a modified build script, so a casual read was unlikely to catch it. Reproducible builds and artifact comparison help.
Sources
- Russ Cox: xz timeline
- Andres Freund: oss-security report, 29 March 2024
- CISA alert on xz Utils, CVE-2024-3094
- OpenSSF Scorecard
Last reviewed: 18 October 2026.
