Curl Just Stopped Taking Bug Reports for a Month. Here's Why That's a Warning Sign

Curl, the HTTP library that ships inside nearly every operating system, container image, and programming language runtime on the planet, spent July 2026 not reading its own bug reports. From July 1 through August 3, the project refused all incoming HackerOne vulnerability submissions. Maintainer Daniel Stenberg called it a “summer of bliss.” It’s also the clearest sign yet that AI-generated noise is starting to break the plumbing that keeps open source secure.

The bounty program died first

The July pause wasn’t the first move. On February 1, 2026, curl shut down its HackerOne bug bounty program entirely, ending a run that had operated since 2019. The reason wasn’t a lack of money. It was that the reports stopped being worth the money.

Stenberg has said that by the time he pulled the plug, the confirmed-vulnerability rate among submissions had dropped below 5%. The rest were what he and much of the security community now call “AI slop”: long, confident, professionally formatted reports generated by pointing an LLM at curl’s source and asking it to find a vulnerability, then submitting whatever came out without checking whether it was real. He estimated he was burning 10 to 15 hours a week just triaging these before he could even get to the small number of legitimate findings underneath them.

That’s not a rounding error. That’s close to a part-time job, unpaid, spent reading fiction about bugs that don’t exist, generated by people chasing bounty payouts or reputation with essentially zero cost to submit and a real cost to evaluate.

Why a fake report costs more than it looks like

A skeptical read of this story is “so what, just reject the bad reports faster.” That undersells the actual mechanics of triage. A well-written AI-generated report doesn’t announce itself as fake. It cites real line numbers, uses correct function names, and describes a plausible-sounding memory safety issue or injection vector in the exact vocabulary a real report would use. Distinguishing it from a genuine finding requires actually reading the code path, sometimes building a reproduction, and often replying to the submitter to ask clarifying questions that go unanswered or get answered by another LLM.

Report type	Cost to submit	Cost to triage
Genuine vulnerability report	High (requires finding + verifying a real bug)	Moderate (mostly confirmation and fix planning)
AI-generated “slop” report	Near zero (prompt an LLM, paste output)	High (requires full manual verification to rule it out)

That asymmetry is the whole problem. When the cost to generate a plausible-looking report approaches zero, the volume scales to whatever the reward structure allows, and the review burden scales with it. A bug bounty program, which exists specifically to reward external reporters, is the worst-designed system for absorbing that shift, because it pays for the exact behavior that’s flooding it.

This isn’t only a curl problem

Curl gets the headlines because Stenberg writes about it in public, on his blog and in interviews, with the kind of bluntness that makes for a good pull quote. But the underlying dynamic isn’t specific to one project. Any codebase with a public reporting channel and no verification gate in front of it is exposed to the same math: mailing lists, issue trackers, and security@ inboxes across the open source ecosystem have reported similar patterns of AI-drafted reports arriving in bulk.

It connects to a broader strain on open source maintenance that predates AI slop by years. We’ve written before about the open source sustainability and funding crisis that leaves critical infrastructure dependent on a handful of unpaid or underpaid maintainers. AI-generated report floods don’t create that fragility, they exploit it. A maintainer with dedicated, funded security staff can absorb a wave of junk reports as an annoyance. A maintainer who is also the primary developer, the release manager, and the only person who understands the codebase’s edge cases cannot, and curl’s Stenberg is close to that description for a library used by billions of devices.

There’s also an adjacent risk worth naming: the same AI tooling that generates plausible-sounding fake vulnerability reports can just as easily be pointed at generating plausible-sounding fake packages, which is the mechanism behind a wave of recent npm supply chain attacks. Slop reports and malicious packages are different attacks, but they share a root cause: automated content generation is now cheap enough to overwhelm the manual trust systems open source has always relied on.

What Stenberg is actually asking for

Reading the coverage, Stenberg’s ask is narrower than “stop using AI.” It’s closer to: don’t submit a report you haven’t personally verified. If your LLM tells you it found a heap overflow, reproduce it before you file it. If you can’t reproduce it, you don’t have a bug report, you have a guess with good formatting, and guesses are not what a security triage queue is for.

He’s also encouraged other maintainers to consider their own scheduled breaks rather than waiting to burn out. That’s a reasonable individual response to an unreasonable structural problem, but it’s not a fix. A monthlong pause moves the backlog, it doesn’t shrink it, and a project can’t take a “summer of bliss” from a real zero-day sitting in its inbox during the pause.

What this means if you ship software that depends on curl (you probably do)

Most engineering teams never think about curl until it’s in a CVE advisory, at which point they’re patching a dependency three layers deep in a container base image. The lesson here isn’t really about curl specifically. It’s about the assumption, baked into how most companies consume open source, that maintenance and security triage happen for free, indefinitely, no matter how much load gets pushed onto it.

A few concrete things worth doing on your side:

• Check whether the open source projects your product depends on most heavily have a funded maintenance model. If they don’t, and you’re a company of any size, sponsoring them is cheaper than the incident response cost of a maintainer walking away.
• If your own security or QA process uses AI to scan code for vulnerabilities, put a human verification step before anything gets filed externally, whether that’s against your own codebase or someone else’s open source project. The habit of “the model said so” is exactly what’s degrading the signal for everyone downstream.
• Don’t assume a bug bounty program is still catching what it used to catch. If a project you rely on has scaled back or shut down its bounty, that’s a gap in your own vulnerability discovery pipeline, not just a curl-side inconvenience.

Curl’s July pause ends, and the bounty program isn’t coming back on the old terms. The report flood that caused both will keep arriving as long as generating a fake finding is free and verifying one isn’t. That’s a problem open source maintainers can slow down for a month at a time, but not one they can solve alone.