In the weeks after the XZ Utils backdoor was disclosed on March 29, 2024, a quieter story circulated in the open source community. It was not about CVE-2024-3094 itself. It was about the human conditions that made the attack possible. Lasse Collin, XZ's solo maintainer, had spent years publicly describing his mental health struggles. Sock puppet accounts had pressured him. Jia Tan had arrived at exactly the right moment with offers of help. The backdoor succeeded because social engineering works, but social engineering works best when the target is already exhausted.
Maintainer burnout is often discussed as a welfare issue, a matter of funding and sustainability. It is also, more uncomfortably, a security issue. A burned-out maintainer is a maintainer who says yes to a co-maintainer request they would otherwise vet. A maintainer with inbox backlog is a maintainer whose security reports sit for months. A maintainer who has given up is a maintainer who hands over the package and stops looking.
The Pattern That Repeats
Marak Squires sabotaged colors.js and faker.js on January 8, 2022. The proximate cause was an infinite loop he introduced himself, but the underlying cause was years of unpaid work on dependencies used by Fortune 500 companies. His GitHub post announcing the sabotage explicitly cited burnout and the refusal of commercial users to fund maintenance. GitHub suspended his account. The packages were orphaned. Downstream users scrambled.
Brandon Nozaki Miller, the RIAEvangelist author of node-ipc, embedded protestware on March 8, 2022 that wiped filesystems on machines geolocated to Russia and Belarus. Unlike the XZ incident, this was not a compromise, it was the legitimate owner exercising control over a package that had accumulated transitive reach far beyond what any single maintainer could reasonably shepherd. Burnout plus political grievance equals unilateral action, and there was no governance layer to prevent it.
Denis Pushkarev's February 2023 post about core-js described a situation of near-total financial collapse. He had been maintaining a package with over 30 million weekly downloads, depended on by approximately half of the top websites on the internet, for the cost of a few hundred dollars per month in sponsorships. He had been through a motorcycle incident and a prison sentence. He was still doing the work.
Then Lasse Collin and XZ Utils. In a June 2022 mailing list post, Collin wrote that he was "not going to disappear, but my ability to care is limited." Jia Tan had been contributing for a year by that point. The pressure campaign from apparent sock puppets was active and visible. The social engineering surface was exposed and well-lit.
Why Burnout Is a Security Property
Burned-out maintainers introduce specific classes of risk that are distinct from ordinary codebase risk.
Delayed patches. A maintainer who has stopped responding to issues is a maintainer whose CVEs do not get fixed. The 2020 Log4j 1.x situation is illustrative: Log4j 1.x had been deprecated since August 2015, but many enterprises were still running it when Log4Shell landed. The reason was partly inertia, but it was also that Log4j 1.x had no one maintaining it to issue a proper EoL-period fix. Maintainer absence is a form of zero-day exposure.
Reduced review quality. Burned-out maintainers merge more quickly and question less. Every time Jia Tan submitted a commit, Collin faced a choice: spend the cognitive energy to review it carefully, or trust the contributor he had come to rely on. Exhaustion pushes that choice toward trust.
Lowered bar for commit access. The most dangerous thing a burned-out maintainer can do is grant commit access to someone they have not properly vetted. The event-stream incident of November 2018 followed this exact script: Dominic Tarr, the original maintainer, handed ownership of the package to a stranger (right9ctrl) who injected cryptocurrency-wallet theft code. Tarr later wrote publicly about the transfer, noting that he had not used the package in years and "the new maintainer expressed interest." This is how package compromises begin.
Abandonment without succession. When a maintainer simply stops, without naming a successor, the package becomes a target for takeover by anyone with a GitHub account and a convincing persona. npm's security team has repeatedly disclosed cases of malicious actors registering expired email addresses associated with npm accounts in order to reclaim ownership. This class of attack is enabled by abandonment, which is enabled by burnout.
The Funding Picture
The funding of critical open source has improved, but not at the speed the problem demands. The Open Source Security Foundation's Alpha-Omega initiative, launched February 1, 2022 with initial funding from Microsoft and Google, explicitly targets the most critical upstream projects. By 2024 it had deployed grants to Python Software Foundation, Rust Foundation, Node.js, Eclipse, and several Apache projects specifically for security hardening and capacity.
The Sovereign Tech Fund, launched in Germany in October 2022, funds maintainer time at individually named critical projects. It has published its investment list, which has included OpenSSL, the GNU Coreutils, Sequoia PGP, and others. The European Cyber Resilience Act, which entered into force on December 10, 2024, pushes responsibilities down the supply chain, creating economic pressure for commercial users to fund upstream.
GitHub Sponsors, launched in May 2019, has distributed hundreds of millions of dollars to maintainers, but the distribution is heavily power-law. A small number of maintainers receive substantial sustained funding. Most maintainers receive essentially nothing.
The structural gap between the value open source produces and the share of that value captured by maintainers remains enormous. That gap is the root cause of burnout, and no amount of individual sponsorship will close it entirely.
What Enterprises Can Actually Do
The common advice, "sponsor your maintainers," is not wrong, but it is insufficient. Sustained engagement matters more than one-time payments. Sustained engagement looks like: assigning specific engineers to be the primary liaison to specific upstream projects, giving those engineers explicit time, and treating upstream work as a first-class deliverable rather than a hobby.
On the security side, the most concrete thing an enterprise can do is treat maintainer health as an input to risk scoring. A dependency whose sole maintainer has publicly posted about burnout is a different risk than a dependency with an active five-person committer base. Ownership transfers, inactive periods, and governance crises are lagging indicators of risk that can be observed and acted on.
Forking is a last resort that should not be framed as hostile. When a project has no maintainers and a commercial user is depending on it, forking and running it internally is a legitimate response. It is how Valkey came out of Redis and how OpenSearch came out of Elasticsearch. The community is often better off for it.
How Safeguard Helps
Safeguard tracks maintainer activity, committer diversity, and governance signals across every open source component in your SBOM, so burnout-driven risks surface before they turn into incidents. Our risk scoring incorporates indicators like maintainer inactivity, recent ownership transfers, and committer concentration, so you can prioritize the handful of dependencies where burnout is creating real exposure. When a critical dependency's maintainer activity drops or a new committer is granted release authority after a brief contribution history, Safeguard alerts your team in time to act. That lets maintainer health inform remediation planning alongside CVE data.