The Curl Maintainer Burnout Story Every AI Developer Should Read

If you have ever filed a security report on an open-source project, the curl story from 2025–2026 is worth your full attention — because the way AI changed that process is a warning about how you might be unintentionally making maintainers' lives miserable. curl is one of the most widely deployed pieces of software on earth, maintained by a tiny team led by Daniel Stenberg. And in early 2026, that team did something telling: they hit pause on their bug-bounty program, drowning not in attacks, but in AI-generated noise.

This isn't an anti-AI piece. It's about the difference between using AI to report a real bug and using it to manufacture a plausible-looking one. The first is welcome. The second is, in Stenberg's words, "AI slop," and it nearly broke a critical project's security process.

What actually happened at curl

According to reporting from The New Stack, BleepingComputer, and Cybernews, curl's HackerOne bug-bounty program — which paid up to $10,000 for a critical vulnerability and $500 for low-severity ones — became a magnet for LLM-generated submissions. Stenberg estimated that about 20% of all reports were being produced with the help of AI tools, while the share of reports describing a real, security-relevant vulnerability collapsed to roughly 5%.

The math is brutal. A maintainer has to read and investigate every report as if it might be real, because the cost of dismissing a genuine vulnerability is catastrophic. When 95% of incoming reports are wrong but written to look right, the team spends nearly all its security time refuting fiction. Stenberg's framing, quoted across the coverage, is that AI slop is effectively "DDoSing open source."

The timeline tells the rest: curl stopped accepting new HackerOne submissions on 1 February 2026, asking researchers to report directly via GitHub instead; reopened a month later when quality briefly improved; and by mid-2026 announced it would not accept or handle any HackerOne reports between 1 July and 3 August 2026 — a deliberate break Stenberg called the project's "summer of bliss."

What "AI slop" looks like up close

The reports weren't lazy one-liners — that's what made them so costly. The standout example, cited by The New Stack, was a submission describing an HTTP/3 "stream dependency cycle exploit," complete with a GDB session and register dumps — that referenced a function which does not exist in curl at all. It was confident, technical, formatted like a real advisory, and entirely fabricated.

That is the signature of LLM-generated security slop: it has the form of expertise without the substance. It cites plausible-sounding internals, includes official-looking artifacts, and uses the right vocabulary — but no one ran the code, reproduced the bug, or checked that the named function is real. The polish is exactly what makes it expensive: a maintainer cannot dismiss it at a glance, so it consumes the one resource the project can't scale, human attention.

The real lesson for AI developers

It is tempting to read this as "AI is bad for security." It isn't — AI is genuinely useful for finding bugs. The failure is in how people report them. Here is how to use AI without becoming part of the slop:

• Reproduce before you report. If you can't trigger the bug with a concrete proof of concept against the actual current code, you don't have a report yet — you have a hypothesis. An LLM's say-so is not reproduction.
• Verify every named symbol. Before submitting, grep the codebase for every function, struct, and code path your report names. The curl HTTP/3 report died on this exact check: the function didn't exist.
• Read the project's policy. Many projects now ask you to disclose AI assistance and to report through specific channels. curl moved reporting to GitHub; respect where a project wants its reports.
• Submit the proof, not the prose. Maintainers want a minimal reproducer, the version, and the impact — not a multi-page AI-written narrative dressed up as an advisory. Length is not credibility.
• Don't chase the bounty with volume. Stenberg directly linked the flood to the cash incentive. Firing AI-generated reports at a bounty program in the hope one sticks is what poisoned the well for everyone.

The underlying principle is respect for a scarce resource. A maintainer's time is the bottleneck in open-source security. AI lowers the cost of producing a report to nearly zero while doing nothing to lower the cost of triaging one — so unverified AI reports shift work from the sender to the maintainer. That asymmetry is the whole problem.

Why this matters beyond curl

curl is upstream of an enormous amount of software, so its security process is load-bearing for the internet. But the pattern generalizes to every project you might contribute to. As AI makes it trivial to generate confident, well-formatted technical text, the scarce and valuable thing is no longer producing a report — it's vouching that the report is real, reproduced, and checked. That vouching is something only a careful human can supply, and it's exactly what the slop strips out.

If the AI era has a new etiquette for open source, it's this: the burden of verification belongs to the sender, not the maintainer. Use AI to find and understand bugs all you want — then do the human work of proving it before you take a maintainer's time.

FAQ

Is curl banning AI-assisted reports entirely? No. The objection is to unverified, fabricated reports, not to using AI as a tool. A real, reproduced bug found with AI help is still welcome — through the project's chosen channel.

Why not just auto-filter the bad reports? Because good and bad AI reports look nearly identical on the surface. The fabricated HTTP/3 report had GDB output and register dumps. Distinguishing real from fake currently requires a human to investigate, which is the cost being exploited.

What should I do if I think I found a curl bug? Reproduce it against the current source with a minimal proof of concept, verify every function you reference actually exists, and report through the project's current channel (GitHub) following its security policy.

Does the bounty incentive really cause this? Stenberg explicitly connected the surge to the bounty. The combination of easy AI generation and a cash reward created an incentive to submit volume regardless of validity.

Bottom line

The curl burnout story isn't a cautionary tale about AI's capabilities — it's about developer responsibility. AI made it free to produce a polished security report and free to fabricate one, while the cost of triaging it stayed entirely on a handful of overworked maintainers. Before you let an agent draft a vulnerability report, do the one thing it can't: reproduce the bug, verify the code is real, and respect the project's process. That discipline is the difference between helping secure open source and DDoSing the people who maintain it.

Sources and further reading