curl is one of those open source projects most people use without noticing. It is in developer terminals, scripts, build systems, containers, operating systems, appliances and products that never show the word curl on screen. That is why its July 2026 decision sounds so strange at first: for a month, the curl project is not accepting vulnerability reports.

Open source maintainer sorting AI-generated vulnerability reports from real findings

Daniel Stenberg called it the curl summer of bliss. From July 1, 2026 at 00:00 CEST until August 3, 2026 at 09:00 CEST, curl's HackerOne submission form is paused. The project says the security email path is also a dead end for this purpose, and that vulnerability reports should wait. GitHub issues and pull requests remain open for ordinary development. Paid support contracts are excluded. The next release, curl 8.22.0, was pushed two weeks later to September 2 so the team has time to deal with whatever piles up after the break.

That is provocative because curl is not a toy package with three users. The curl command-line tool and libcurl library sit in enough software that security teams treat them as infrastructure. The open source reflex says: if someone finds a serious bug, the responsible thing is to report it privately and quickly. curl's July policy says: yes, but maintainers are human, and the intake line itself has become a denial-of-service target.

The new pressure point is not only malicious spam. It is plausible reports that cost almost nothing to produce and still require expert humans to disprove. AI has made it cheap to generate vulnerability-shaped prose: a confident title, a severity guess, a code explanation, maybe a proof-of-concept that looks technical at a glance. If the bug is real, great. If the bug is imaginary, obsolete, unreproducible or based on a function that does not exist, someone who understands curl still has to read it carefully enough to reject it.

That is the asymmetry the curl story exposes. AI made writing a report easier. It did not make curl maintainers' verification time cheaper.

What curl actually paused

The important detail is scope. curl did not stop development for July. Public GitHub issues and pull requests remain open. The project is not refusing normal bug fixes, code review or ordinary community work. What it paused is the vulnerability disclosure intake: reports that would normally enter through HackerOne, with private handling by a small trusted group.

Stenberg's June 15 post is unusually direct. The project will not accept or otherwise handle any vulnerability reports during July 2026. The HackerOne form is paused. Email will not be used as a bypass; curl does not accept vulnerability reports over email in general. Reports should wait until August 3.

The post also makes the human reason plain. The maintainers had been under huge pressure for roughly four months and did not expect the flood to be over. The break is meant to lower pressure, allow actual vacation, and let maintainers breathe. The phrasing is light, but the infrastructure lesson is serious: even critical open source projects cannot run an always-on emergency desk forever if the people staffing it are volunteers or a tiny funded group.

Paid support contracts remain serviced. That line annoyed some readers and reassured others. It makes the implicit economics visible. If a company depends on curl enough to need guaranteed security response in July, the project is saying there is a paid path for that. Everyone else is being asked to respect a maintenance boundary.

Why this belongs in Open Source Radar

This is worth watching not because every project should copy curl's July pause. Many projects cannot. Some have institutional security teams, foundation backing, vendor SLAs or regulatory obligations. Others are too small for a formal policy at all.

The reason it matters is that curl is a readable case study of a wider open source bottleneck. Vulnerability reporting has long assumed that more reports are better. More eyes, more findings, more responsible disclosure, fewer bugs. That model breaks when the marginal cost of sending a plausible report collapses while the cost of evaluating it stays high.

A bad AI-assisted report is worse than obvious spam. Spam can be deleted. A report that mentions real files, real functions and real security vocabulary may take a maintainer half an hour, two hours or a day to reproduce, trace, discuss and reject. If enough of those arrive, the queue does not merely get annoying. It delays real fixes, releases, sleep and paid work.

curl is also a useful example because its policy page now explicitly tells reporters to write briefly and clearly in their own human voice and not lazily paste massive AI-generated explanations. That is not anti-AI purity. It is a request to respect the recipient's attention. If you use a model to help find or explain a bug, the burden is still on you to verify, minimize and present the evidence.

The Hacker News argument

The Hacker News thread attached to Stenberg's post had 793 points and 316 comments when checked through the API snapshot. That is not representative of the whole world, but it is a strong signal that developers and maintainers recognize the conflict.

One camp cheered the vacation. Open source maintainers should be allowed to be unreachable. The internet has built too much commercial value on the idea that someone else will provide free urgent expert labor forever. If enterprises need July coverage, they can sponsor, hire, or buy support.

Another camp worried about the obvious sentence in the post: bad guys will not rest. What if a real high-impact curl vulnerability is found during the pause? What if a researcher wants to disclose responsibly and is told to come back in August? What if coordinated disclosure depends on the upstream project being reachable?

Both concerns are valid. The answer is not that security can take a vacation with no risk. The answer is that permanent exhaustion is also a risk. A burned-out maintainer may miss a real issue in September because July was spent rejecting synthetic noise. A project without boundaries may lose the people who know the code well enough to fix the hard bugs.

The more interesting HN debate was about responsibility. Is a critical dependency allowed to close the door? Are users entitled to response because curl is important? Or does importance increase the duty of companies to fund the project rather than demand free availability? The thread did not settle that question. It did show that the old bargain is fraying.

Why AI-shaped reports are different

Security programs have always received weak reports. False positives, duplicate findings, scanner output, misunderstood threat models and hopeful bounty submissions are not new. The difference in 2026 is scale and polish.

A low-quality human report often looks low quality. It may be vague, short, confused or obviously copied from a scanner. An AI-assisted report can be long, well structured and fluent while still being wrong. It may cite a plausible memory safety pattern, invent a code path, misread a fixed bug, or produce a proof-of-concept that does not trigger the claimed behavior.

That polish steals triage time. A maintainer cannot reject it simply because it looks silly. The report might be the one real bug hidden among twenty confident hallucinations. The more important the project, the harder it is to dismiss anything quickly.

This is the same pattern seen in other knowledge work: the generator's cost falls faster than the verifier's cost. For open source security, the verifier is often the rarest person in the system: someone who knows the codebase, the protocol, the release process and the historical CVE boundary.

curl's vulnerability process is already structured

The current curl vulnerability disclosure policy is not an improvised mailbox. It tells reporters not to use the public bug tracker for security issues, because premature disclosure can harm users. Reports go through HackerOne to selected trusted people. The team acknowledges, investigates, rejects or accepts, works on fixes, considers impact and coordinates release timing.

The security page lists 206 published curl/libcurl vulnerabilities at the time of checking, with many June 24, 2026 entries marked low or medium in the visible recent table. That history matters. curl is not pretending security does not exist. It has a long record of documenting and publishing issues.

The project also no longer offers a bug bounty. The disclosure policy says there is no bug bounty and curl never offers rewards for reported vulnerabilities. That changes the incentives. A program can still receive reports without paying for them, but if public reputation, automation and potential future value attract low-quality submissions anyway, removing bounties is not enough to remove the triage load.

The broader pattern

curl is not alone. The libexpat issue opened by Sebastian Pipping says the project is following curl's announcement with a break from new vulnerability reports until August 1, while continuing work on known unfixed vulnerabilities and upcoming releases. That is a smaller data point, but a telling one. Maintainership fatigue spreads because the same automation pressure hits many public inboxes.

The broader question for open source is not whether maintainers deserve vacations. Of course they do. The question is how security intake should work when report generation is cheap, global and partly automated.

Some projects may need stricter templates: minimal reproducer, affected versions, exact commit, expected behavior, actual behavior, exploitability reasoning, and a short explanation of how the reporter verified the result. Some may need reporter reputation or rate limits. Some may need triage partners, foundations, paid support tiers, or shared security desks. Some may need published availability windows so users know when not to expect immediate response.

None of this is perfect. Rate limits can block real researchers. Reputation systems can exclude newcomers. Paid support can create an uncomfortable split between companies with money and users without it. But pretending that maintainers can absorb infinite AI-shaped reports is worse.

What maintainers can copy without copying the pause

The first useful move is to make evidence requirements explicit. A vulnerability report should not be a model-written essay. It should include a minimal reproducer, affected version, tested environment, expected and actual behavior, impact, and why the issue crosses the project's security boundary. If AI helped write it, the human reporter should still own every claim.

Second, separate security reports from general issues, but do not let the security channel become an unbounded free consultancy. Use templates that reject walls of text. Ask for concise reports. State that unverifiable AI-generated submissions may be closed without extended discussion.

Third, publish response expectations. A tiny volunteer project should not imply 24/7 security operations. A library used by companies may need clearer language: best effort for the public, faster response for contracted support, emergency contacts for distributors or foundations where appropriate.

Fourth, gather metrics. How many reports arrive? How many are real? How many are duplicates? How many are AI-shaped noise? How many hours does triage consume? Without numbers, the conversation becomes moral theater: grateful users versus exhausted maintainers. With numbers, sponsors and companies can see the cost.

Fifth, protect rest as infrastructure. A project that depends on one or two people cannot treat their attention as infinitely renewable. Vacation policy is not a lifestyle perk. It is continuity planning.

What companies should learn

If your product depends on curl, libcurl, expat, OpenSSL, zlib, SQLite, Linux distributions, Kubernetes components or other open source infrastructure, do not outsource validation of your risk to unpaid maintainers. Maintain a dependency inventory. Know where curl is used. Know which versions are in shipped products. Test security updates. Sponsor projects or buy support when the dependency is critical.

If your AppSec team uses AI to find vulnerabilities, put human validation before upstream reporting. Do not send a model's theory to a maintainer and ask them to finish the work for free. Reproduce it. Reduce it. Confirm the affected version. Remove speculative severity language. Say what you know and what you do not know.

The ethical rule is simple: if your tooling makes it cheaper for you to create work for someone else, you are responsible for filtering before you send it.

The risk of the July pause

There is still a real downside. A serious curl issue could be found in July. A well-intentioned researcher could wait. A downstream vendor could make a private patch. Attackers would not politely observe the calendar.

That risk should be acknowledged, not waved away. The best argument for the pause is not that it is harmless. The best argument is that the alternative was also harmful: an overrun triage queue, maintainers under sustained pressure, and a security process increasingly shaped by false confidence from automated reports.

For users, the practical response is boring. Keep systems updated. Track curl advisories after August 3 and the September 2 release. If you run a high-risk product that needs guaranteed response, pay for the support path or maintain your own ability to patch and validate. If you are a casual user, do not panic because a disclosure intake is paused; monitor normal distribution updates.

The bottom line

curl's summer of bliss is not a universal template. It is a flare. It tells the open source world that security intake is now part of sustainability, not a side channel that can quietly absorb infinite work.

AI may help find real bugs. Good researchers still matter. Responsible disclosure still matters. But a report is not responsible just because it has vulnerability-shaped formatting. The responsible part is the human verification before it lands in a maintainer's queue.

The next generation of open source security will need better scanners, yes. It will also need better gates: proof requirements, rate limits, paid triage, shared support, clearer disclosure windows and the cultural permission for maintainers to say no before the queue eats the project.

curl is taking July off from vulnerability reports. The rest of open source should not just watch the vacation. It should study the inbox that made the vacation necessary.