AI has inverted the economics of open source. It is now cheaper to generate a bug report, a patch or a security advisory than to read one, shifting the cost of open source onto the few humans still doing verification. One working maintainer summed it up: “AI has made our job harder, it has really flipped the script.” The bottleneck has shifted from writing code to reviewing it.
Three forces follow from that shift, and they chain together: AI slop floods maintainers, burnout follows, and the XZ Utils backdoor shows what happens when a burnt-out, unpaid maintainer becomes a soft target. This is one chapter of the wider story behind the forces behind the reckoning.
Why are AI agents and AI-generated reports making the maintenance load worse?
AI collapses the cost of producing reports and code while the human work of reviewing and fixing stays fixed. Generation scales with AI; verification does not. Curl is where the asymmetry became measurable.
curl ran a bug bounty for six years, paying out over US$90,000 for 81 genuine, fixed security problems before it stopped working in 2025. Around 20% of submissions were AI slop, and the share that turned out to be genuine vulnerabilities had fallen from roughly 15% to under 5%. Daniel Stenberg, maintainer of curl and libcurl, shut the bounty down, writing that the project needed to “reduce the amount of sand in the machine.”
The noise is not obvious spam. One curl report described an HTTP/3 “stream dependency cycle exploit” complete with GDB sessions and register dumps, all referencing a function that does not exist in curl. It takes about thirty seconds to generate a patch like that and several hours to review it. Each lands on a seven-person volunteer security team, turning the inbox into a denial-of-service target. This is the Vulnpocalypse: findings generated faster than anyone can triage.
Faced with that inbox, re-implementing the spec locally can look simpler than depending on the library. But that misses where the bugs live. A spec is not the code. Years of edge cases, undefined behaviour and undocumented fixes live in the gap, and re-implementing the spec moves the risk onto your own unreviewed code. It’s a dependency-risk decision.
AI also cuts the other way. Google’s Big Sleep found a real stack buffer underflow in SQLite, and Anthropic’s Claude found 22 Firefox vulnerabilities in two weeks, 14 of them high-severity. The capability is real; the problem is the asymmetry. The same technology that finds real bugs also buries them in noise.
What actually breaks when a one-person critical dependency loses its maintainer?
The people absorbing that flood are usually the same understaffed maintainers. When a one-person dependency loses its maintainer, security response, releases and fixes all stop at once. Consumers inherit silent dependency debt: unpatched vulnerabilities and broken upgrades nobody notices until something fails.
The metric for this is bus factor, the number of people who would have to be hit by a bus before a project stalls. Research on the top open source packages found a median bus factor of 1. One person’s illness, burnout or departure halts a project you depend on. There are plenty of them: 60% of maintainers are unpaid, 61% of them work alone, and nearly 60% have quit or thought about quitting.
You can read the signal with a few questions. Who else can commit and issue a release today? When did someone other than the lead last contribute? Is succession or funding documented? What is the real response time on a reported vulnerability? If the honest answers are “nobody” and “only the lead,” you are carrying dependency debt.
The debt compounds. Kubernetes’ Ingress NGINX controller, used in roughly half of all cloud-native environments, was maintained for years by one or two developers working evenings and weekends before it entered retirement with no security patches after March 2026. This is the sustainability question made concrete, and it traces back to the funding gap that fuels burnout.
How was maintainer burnout weaponised in the XZ Utils backdoor?
Burnout is a human cost and an attack surface. An attacker posing as “Jia Tan” spent roughly three years building trust and pressuring the exhausted sole maintainer, Lasse Collin, until he gained commit access, then planted CVE-2024-3094 in XZ Utils. It was caught only when Andres Freund noticed SSH logins taking about 500 milliseconds instead of the usual 100.
The takeover was patient. A first innocuous patch arrived in late 2021, and by the end of 2022 “Jia Tan” was merging commits directly. Suspected sock-puppet accounts with no public presence in software pressured the over-stretched maintainer to hand over control. Collin’s burnout was visible long before the attack matured; in June 2022 he wrote that his “ability to care has been fairly limited”.
The backdoor scored CVSS 10.0 and lived only in the release tarballs, not the git repository, so it never appeared in the source as a readable backdoor. Undetected, it would have handed its creators a master key to the hundreds of millions of computers that run SSH, as Alex Stamos put it. It was caught by luck. Attackers are learning to treat maintainer burnout as an attack surface, and burned-out, unpaid maintainers are exactly who such campaigns exploit. That is the supply chain risk made real, and it comes back to the funding shortage behind burnout.
Where this leaves you
The three headlines are one mechanism. AI slop is a cost-shift onto reviewers. Burnout is the human cost of that shift. XZ Utils is the consequence of both. The counter-current shows the same technology can be turned against the noise, so this is not hopeless.
The practical step is to read each dependency as a question of bus factor and maintainer continuity. Assessing your own bus factor is where that work begins, and why this matters beyond one project is the wider reckoning it feeds into.
Frequently Asked Questions
What exactly is “AI slop” in open source?
AI slop is the flood of low-quality, machine-generated bug reports, code patches and security advisories submitted to open source projects. It is not outright malicious, but it is cheap to produce and expensive to verify, so it clogs issue trackers and pulls maintainer attention away from genuine problems. At scale, it behaves like a slow denial-of-service attack on the humans doing the reviewing.
Why did curl get rid of its bug bounty?
curl’s maintainer Daniel Stenberg shut down the project’s US$90,000 bug bounty because AI-generated noise made the program unworkable. Genuine reports had fallen from around 15% of submissions to under 5%, even as total volume climbed. A bounty only works when real reports dominate the inbox; once junk does, paying for reports just funds the triage of noise. Stenberg redirected that money elsewhere.
What questions reveal a dependency’s bus factor and maintainer continuity?
Ask who else can commit and issue a release today, and when the last contribution came from someone other than the lead. Check whether succession or funding is documented, and what the real response time is on a reported vulnerability. If the honest answers are “nobody” and “only the lead”, the project has a bus factor of one and your continuity depends on a single person.
Consuming an external library versus re-implementing the spec locally with AI: which is safer?
Neither is automatically safer, and the comparison misses where bugs actually live. Re-implementing a spec with AI does not reproduce the years of edge cases, undefined behaviour and undocumented fixes baked into a vetted library. The risk simply moves from the library’s maintainers to your unreviewed code. Treat the choice as a dependency-risk decision, not a shortcut.
Can AI actually find real vulnerabilities, or does it only create noise?
AI does both, and mature tools show it finding genuine bugs. Google’s Big Sleep agent caught a real flaw in SQLite, and Anthropic and Mozilla’s work on libxml2 surfaced legitimate issues. The problem is not the capability but the asymmetry: AI finds and files faster than humans can verify, so the same technology that finds real bugs also buries them in noise.
Is the xz backdoor the first time a trusted open source project was compromised?
No. Open source supply chain attacks predate xz, including the npm event-stream incident, where a burnt-out maintainer handed his package to a stranger who inserted malicious code. What makes xz significant is its method: an attacker spent months cultivating a trusted position through social engineering rather than exploiting a technical flaw, treating social pressure on an exhausted maintainer as a viable attack vector.
Does the xz backdoor mean open source is unsafe?
No, and that reading misses the point. The backdoor was caught because the code was inspectable and someone noticed odd behaviour, something closed-source software rarely allows. The lesson is not that open source is unsafe, but that its security depends on people, and those people are underfunded and overstretched. The fragility is a funding and governance problem, not proof the model failed.
Could antivirus software or a scanner have caught the xz backdoor?
Unlikely. The malicious code lived in test fixtures and was assembled at build time, so it never appeared in the source as a readable backdoor and left no obvious signature to match. It was caught by chance when Andres Freund noticed slow SSH logins and investigated. Routine scanning might not have flagged it, which is why human attention and reproducible builds matter as defences.
What is “dependency debt”?
Dependency debt is the hidden security and maintenance obligation you inherit by relying on a package you do not control. It stays invisible while a project is healthy, then surfaces as unpatched vulnerabilities, stalled releases or broken upgrades the moment its maintainer steps away. It is the practical cost of a supply chain built on single maintainers, and it only becomes obvious after something fails.
What is the Vulnpocalypse?
The Vulnpocalypse is the flood of security reports generated faster than maintainers can triage them, largely fuelled by AI tooling. It turns maintainer attention into a denial-of-service target: the queue grows, real vulnerabilities get buried, and exhausted volunteers either burn out or step back. The volume itself becomes the threat, even when the individual reports are not malicious.
Who was “Jia Tan”?
“Jia Tan” is the alias used by the attacker who gained commit access to XZ Utils and planted the backdoor. The persona is widely believed to be a cover identity rather than one verified individual, and it was supported by other suspected sock-puppet accounts that pressured maintainer Lasse Collin to hand over control. Treating the alias as one person oversimplifies a coordinated, patient campaign.
What can organisations do to support the maintainers they depend on?
Start by measuring: identify your critical single-maintainer dependencies and fund the ones you genuinely rely on. Donate money, assign engineers to contribute patches, and help with the unglamorous work of triage and releases. Support does not have to be dramatic. Paying a maintainer or reducing their load directly lowers the burnout that attackers exploit.
