Curl Killed Its Bug Bounty Over AI Slop. The Real Problem Is an Economics One.

What curl's AI slop problem actually looked like

At the end of January 2026, curl maintainer Daniel Stenberg pushed a commit whose filename left no room for interpretation: the project's bug bounty program was over, and AI slop is why. Curl runs on a small handful of volunteer maintainers who read every report landing in its HackerOne inbox, and by the middle of 2025 the shape of the problem was already visible in curl's own numbers. Roughly 5% of submissions turned out to be real, exploitable issues. Around 20% carried the fingerprints of an AI-written report: correct function names, a plausible file path, a writeup formatted like a CVE advisory, and nothing underneath it once someone actually checked.

The bounty had paid real money for real bugs for years. What ended it wasn't the sheer number of low-quality submissions, it was how expensive each one had become to rule out. A report that looks wrong is fast to dismiss. A report that looks right, uses the correct vocabulary, references a real code path, and is simply describing a condition that doesn't exist takes a maintainer's actual attention to disprove.

Five months later, curl went further. Starting 1 July 2026, curl and the libexpat XML parser paused HackerOne intake entirely for about a month. Stenberg and libexpat maintainer Sebastian Pipping both described the break, informally, as one the projects had earned.

Node.js hit the same wall from a different angle

Node.js didn't close its bug bounty. It changed who's allowed to open one. Since 19 February 2026, a new HackerOne submitter needs a Signal score, HackerOne's own reputation number built from how often that researcher's past reports turned out to be valid, of 1.0 or higher before their submission reaches a human triager. Below that line, the report simply isn't read by a person.

Node's security team had spotted the same pattern curl had: batches of reports describing the same handful of code paths, in near-identical phrasing, written in the confident, evenly formatted register of a tool rather than the uneven style of someone who'd actually read the source. In the single month between 15 December 2025 and 15 January 2026, the project logged more than 30 reports of this kind landing on the same narrow set of files, each one requiring a maintainer to open the code before ruling it out.

Researchers without an established Signal score aren't shut out entirely. Node.js redirected them to the OpenJS Foundation's Slack instead, a slower channel, but one a person actually reads.

This isn't spam. It's a cost curve.

The instinct is to file this under spam moderation, the same problem email solved two decades ago. It isn't the same problem, and the difference is worth being precise about.

A spam filter works because spam is cheap to produce and cheap to recognise: mismatched sender domains, mangled grammar, links to nowhere. An AI-slop vulnerability report is cheap to produce and expensive to recognise. It uses the real function names. It follows the structure of a genuine advisory. Ruling it out means opening the codebase and checking whether the described condition actually exists, which is precisely the step a maintainer would take for a real report too.

Before generative tooling, the cost of writing a plausible false report roughly tracked the cost of triaging one; you needed to understand the code either way, so bad-faith reports were rare and cheap fakes were easy to spot. Generative tooling split that equation apart. Producing a report now costs one prompt. Ruling one out still costs a maintainer's afternoon.

None of this is an argument that AI tooling is only a drain on maintainers. Some projects use the same class of models on the other side of the queue, for a first pass that flags the reports worth a human look. The asymmetry isn't that AI is bad for triage, it's that submitting and triaging aren't symmetric jobs to begin with, and only one side of that exchange has been automated at scale so far.

The capacity behind these projects was already thin

None of this landed on a well-resourced system. One widely cited maintainer survey put the share of open-source maintainers who receive no payment at all for their work at around 60%. GitHub Sponsors crossed $100 million in total funding in July 2026, a real milestone, and still a small number spread across an ecosystem that underpins a large share of downstream commercial software.

Kubernetes' Ingress NGINX controller shows what happens when that capacity runs out for an entirely different reason. In January 2026, the project's Steering and Security Response Committees announced that Ingress NGINX would move to best-effort maintenance until March 2026, after which there would be no new releases, no bug fixes, and no security patches. The stated cause wasn't AI-generated noise. It was a controller carrying years of legacy scope, maintained by too few people, that the Kubernetes project chose to retire in favour of its newer Gateway API standard rather than keep propping up.

The mechanism is different from curl's. The resource running out is the same one: a small number of people, often unpaid, who are the only ones who understand software that a large number of companies quietly run in production. AI-generated noise lands directly on top of that same limited resource, whatever else is also straining it.

External Secrets Operator, a project widely used to sync credentials into Kubernetes clusters, made the point even more directly. Its remaining maintainers paused new releases after four people quit in early 2026, saying plainly that funding doesn't review pull requests or manage releases, people do, and the project didn't have enough of them left. By June 2026 new contributors had stepped in and development resumed, which is the encouraging half of the story: visibility can pull help in. It's also the less comfortable half, since the project ran for months on effectively one person before anyone outside its user base noticed.

What's actually changing in response

Reputation gates. Scheduled pauses. Direct funding. None of these individually would have looked necessary five years ago, and each is now live somewhere in the ecosystem, not as a full fix but as this year's version of triage.

Node's Signal-score requirement is the sharpest version: it doesn't try to detect an AI-written report, it changes who gets to submit one in the first place. Curl's scheduled pauses are the blunter version, a fixed window where the queue simply doesn't grow. Germany's Sovereign Tech Fund is the slower, structural version, having committed more than €1 million to KDE's core infrastructure in 2026 alone and earmarked funding for systemd, PHP, and the Servo browser engine into the same year, on top of roughly €24.6 million committed across more than 60 projects since 2022.

None of these is a full answer. A reputation gate keeps out low-Signal newcomers along with low-Signal AI output, and a funded maintainer is still one person deciding what to review first. What they share is an admission that the old assumption, that anyone motivated enough to write a plausible report deserves a maintainer's time, no longer holds.

The part that matters if you've never filed a bug report

This reads like a maintainer problem until you notice who else is watching the same signals. Auditors already flag end-of-life open-source components against SOC 2, PCI DSS, HIPAA, and ISO 27001 controls, and Ingress NGINX's March 2026 cutoff means any vulnerability found in it after that date will never be patched upstream, by design.

A company's dependency graph doesn't distinguish between a project with two overworked maintainers being flooded by AI-generated reports and a project with two overworked maintainers for entirely separate reasons. Both produce the same outcome eventually: patches slow down, then stop. Tracking CVE counts against a dependency answers whether something has gone wrong yet. It doesn't answer how much slack is left in the two or three people who'd notice if it did.

What to watch next

Expect the Signal-gating model to spread past Node.js, because it scales without asking a maintainer to read more. Whether funding scales with it, whether more Sovereign Tech Fund-style commitments show up before more Ingress NGINX-style deadlines, will decide whether this settles into a manageable cost of running open infrastructure or turns into a slow trickle of quiet, unpatched end-of-life notices. What's already visible is which resource actually runs open source in 2026. Not code. The fixed number of people willing to read the next report closely enough to know whether it's real.