Stenberg argues that the asymmetric cost between generating AI-slop reports (~30 seconds, free) and verifying them (30-90 minutes of skilled volunteer time) has made the existing intake model untenable. He frames the July pause as a pragmatic reset for a two-to-three-person triage team that can no longer keep pace with exponential submission volume, and points to his documentation since 2024 showing the share of useless reports rising every quarter.
By submitting the post and driving it to 612 points, the submitter implicitly endorses Stenberg's framing that this is a watershed moment for critical-infrastructure OSS. The high engagement signals broad agreement that linear human triage effort cannot scale against LLM-generated submission volume.
The editorial frames curl's pause as the first time a critical-infrastructure OSS project of this scale has formally suspended vulnerability intake, calling it a structural failure rather than a one-off stunt. It argues the asymmetry between cheap LLM generation and expensive human verification is the whole story, and that bounty programs as currently designed cannot survive it.
On June 15, 2026, Daniel Stenberg published a post titled "Curl Summer of Bliss" on his personal blog, announcing that the curl project will not accept any new vulnerability reports — via HackerOne or any other channel — for the entire month of July 2026. The post hit 612 points on Hacker News within hours of going live. The reasoning was characteristically blunt: the curl security team, a small group of volunteers, can no longer keep up with the deluge of low-quality and AI-generated submissions, and the only way to reset is to close the door entirely for thirty-one days.
This is the first time a critical-infrastructure OSS project of curl's scale has formally suspended its vulnerability intake, and it is happening because LLMs broke the economics of bug bounties. Stenberg has been documenting the AI-slop problem in public since at least early 2024, when his post "The I in LLM stands for intelligence" catalogued reports featuring hallucinated CVE IDs, fabricated stack traces, and code paths that simply do not exist in the curl tree. By his own accounting in subsequent posts, the share of useless reports has risen monotonically every quarter. The July pause is not a stunt; it is a triage team conceding that linear effort cannot keep up with exponential submission volume.
The mechanics matter. Curl runs its disclosure program through HackerOne, with a bounty pool funded by sponsors. Anyone can submit. The triage queue, in practice, is two or three people. During July, submissions will be rejected automatically, and the team will spend the month on the existing backlog and on writing — not reviewing.
The asymmetry is the whole story. It costs an LLM-wielding submitter roughly thirty seconds and zero dollars to generate a plausible-looking vulnerability report; it costs a curl maintainer thirty to ninety minutes to verify it is fiction. Multiply that by the number of bounty hunters who have figured out that "prompt Claude with the curl source tree and ask for memory safety issues" produces output that at least *looks* like a finding, and you arrive at curl's current inbox.
The HackerOne incentive structure makes this worse, not better. Submitters are paid for valid reports but not penalized in any economically meaningful way for invalid ones. Reputation systems on bounty platforms are weak and easily reset. The result is a classic externality: the cost of submission has fallen by three orders of magnitude while the cost of triage has stayed flat, and the maintainers are the ones absorbing the difference.
Second, this is not a curl-specific problem; curl is just the project willing to say it out loud. OpenSSL, the Linux kernel, OpenJDK, and the major language runtime teams all run inboxes with similar structural exposure, and they are watching how the curl pause is received. The Linux kernel security team has made noises about quality thresholds for over a year. The Python security team has discussed adding friction. None of them have pulled the trigger yet because the optics are bad — refusing security reports looks negligent to people who do not understand the volume problem. Stenberg's calculation is that the optics of a planned, time-boxed pause are survivable in a way that ad-hoc rejections are not.
Third, the broader bug bounty industry has a credibility problem developing in slow motion. HackerOne and Bugcrowd have not, publicly, addressed LLM-generated submissions with any kind of platform-level intervention. There is no proof-of-work, no submission fee, no identity verification beyond an email address. The platforms profit from volume; the projects pay for triage. Until that economic mismatch is fixed — through pricing, friction, or reputation slashing — every project on these platforms is one viral LLM-prompting tutorial away from a curl situation.
The community reaction on the Hacker News thread is split in a revealing way. One camp treats this as obvious and overdue. Another camp argues curl should hire dedicated triagers, ignoring that the bounty pool does not generate enough to fund a salary and that maintainer compensation in OSS remains a separate, unsolved problem. A smaller but loud group blames Stenberg personally for not "using AI to triage AI," which assumes the triage problem is pattern-matching rather than verification — a category error. You cannot LLM your way out of a problem where the failure mode is plausibility without correspondence to reality.
If you depend on curl — and you do, because libcurl is in your container base image, your language's HTTP client, your build toolchain, and probably your phone — the July gap has concrete consequences. Coordinated disclosure timelines that touch curl will stall. If your security team finds a libcurl-related issue in late June, you have two weeks to coordinate before the inbox closes; if you find one in mid-July, you wait. Plan accordingly. Move any internal curl-related security work that requires upstream input into June or August.
For anyone running a bug bounty or vulnerability disclosure program, this is the cue to audit your own submission pipeline before you become the next curl. Concretely: instrument what percentage of your reports require more than fifteen minutes to dismiss, track the trend line, and if it is climbing add friction now rather than after a public meltdown. Reasonable friction options that have worked elsewhere include requiring a reproducible proof-of-concept artifact (not just prose), gating submissions behind a low-cost identity step, and reputation-weighting based on prior valid submissions. A small refundable submission deposit is heretical in the bounty world but increasingly defensible.
The deeper audit is internal. If your security org has bought into LLM-assisted vulnerability research — and most have, quietly — you are part of the problem distribution. There is a difference between an analyst using an LLM to summarize a real finding they have verified and a hunter shipping unfiltered model output to a maintainer's inbox. Make sure your tooling cannot produce the latter, intentionally or accidentally. Dependency-bot pipelines that auto-file security tickets based on LLM analysis of changelogs are particularly suspect; verify yours actually verifies.
The July pause will work — curl will catch up, the backlog will shrink, Stenberg will write the retrospective in August — and then the problem will return in September, because nothing about the underlying incentive structure has changed. The interesting question is what the second-order effects look like across the OSS security ecosystem. The most likely outcome is that 2026-2027 becomes the period when major projects unbundle from open bounty platforms and replace them with vouched, identity-gated, lower-volume disclosure programs — closer to how kernel security has historically worked than how curl has. That trade restores signal at the cost of accessibility, which is a real loss; the next-generation researcher who would have made their name on a curl bounty will have fewer on-ramps. But the alternative is the slow strangulation of volunteer triage capacity across the projects everyone depends on, and curl just demonstrated that the slow version of that strangulation has a fast-forward button labeled "GPT-class model."
> > The bad guys won’t rest> Probably not. But we will.A pleasant dose of humanity in decidedly inhuman times.
For the people here who want to do the same when they are vacation (be completely detached from work): Make it impossible for you to work! Leave your work devices behind! Log out of all accounts, remove 2FA keys after backing them up on paper and tell your partner to not give them back to you for th
Both libexpat ("Expat") and uriparser are following the curl security vacation and will not accept new vulnerability reports before 2026-08-01, starting today.[1] https://github.com/libexpat/libexpat/issues/1277[2] https://github.com/uriparser&#
For anyone who thinks this might matter for security:* curl is mature enough that the chance of an impactful bug is basically zero * if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co * if there is such a bug, it's more important that it gets pa
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The headline buried the lede -- this is a way to get some summer vacation (niiice) AND encourage enterprise support contracts, which will still have availability. I don't think I've heard of this particular open source / support / summer vacation business model before but I like