RC RANDOM CHAOS

curl pauses security report intake for July

curl is closing its vulnerability intake for July 2026 to survive AI-generated report spam, and the precedent it sets for open source disclosure.

· 7 min read

curl runs inside something north of twenty billion installations, by the project’s own count: phones, cars, routers, payment terminals, set-top boxes, and a fair number of things in orbit. For a stretch of July 2026, the people who maintain it will not read new vulnerability reports. The intake channel closes. The bug bounty pauses. Anyone who finds a flaw in libcurl that month has to hold it, drop it in public, or wait.

That sentence sounds worse than the reality, and the reality is still a problem worth understanding. Most coverage will frame this as “company stops accepting security reports,” which gets two things wrong before it starts.

curl is not a company, and that is the whole point

There is no curl Inc. There is no security operations center, no rotating on-call, no SOC analyst paid to read your report at 3 a.m. curl is an open source project carried by Daniel Stenberg and a small volunteer security team. Stenberg has worked on it since 1998. The code sits in billions of devices owned by companies that have never paid the project a cent and never will.

So when the headline says a vendor “refuses” reports, picture the actual mechanism. A handful of humans read every submission, reproduce it against a codebase they know line by line, and decide whether it is real. There is no second shift. When those humans step back for a month, the door does not stay open with a skeleton crew behind it. It shuts.

This matters because most of the software you depend on runs the same way. OpenSSL, curl, zlib, the libraries underneath your bank’s app and your car’s firmware. The maintainer count for critical internet infrastructure often rounds to one. A month-long pause at curl is a stress test for a model the whole industry quietly relies on.

The intake stage broke before anyone budgeted for it

curl pays real money for real bugs through HackerOne and has handed out tens of thousands of dollars over the years. The program worked because writing a credible vulnerability report used to take skill. You had to read C, understand memory safety, build a proof of concept, and write it up. That cost filtered out most noise.

Large language models removed the cost. Stenberg started documenting the result in early 2024: reports that look correct, carry CVE-style language, cite function names and stack traces, and describe bugs that do not exist. The function names are hallucinated. The stack traces are invented. The vulnerability is fiction dressed in the format of fact.

Here is the asymmetry that breaks the system. A submitter generates one of these in thirty seconds at zero cost. A maintainer who knows the code still has to read it, take it seriously, attempt to reproduce it, and prove the negative before dismissing it. The expensive side is the defender. The free side is the firehose. Stenberg has called the volume a denial-of-service attack on the security team’s attention, and the description fits. You do not need to take down a server if you can exhaust the three people who triage its bugs.

In software development lifecycle terms, the intake stage has no rate limit and no cost to the sender, while supply on the sender side is now effectively infinite. Any pipeline with those properties floods. curl’s response is to close the valve for a month and let the humans recover.

The economics matter because curl tried to do this right. It built a paid program specifically to attract skilled researchers, and for years the money bought signal. A bounty assumes that a payout is worth more than the effort to earn it honestly, so honest work dominates. Generative tools inverted that math overnight. Now the cheapest way to chase a payout is to mass-produce plausible reports and hope one lands, and the program’s own incentive structure rewards the flood it was built to filter. A pause is the only lever left that does not require rebuilding the whole intake system mid-crisis.

What a closed window does to your actual security posture

The slop is annoying. The slop is not the risk. The risk is the one genuine, serious vulnerability that someone finds in week two of July, with nowhere to send it.

Responsible disclosure is a contract. The researcher agrees to sit on a working exploit and keep it private. The maintainer agrees to fix it on a clock and ship an advisory. Users get a patch before attackers get the details. The whole arrangement holds because there is a live channel connecting the two sides.

Close that channel and you weaken your half of the contract. A researcher sitting on a remote code execution bug in libcurl during the pause has bad options. Hold it and hope nothing leaks. Post it publicly and force a scramble. Sell it to someone who will not be polite about it. None of those serve the people running curl in production, which is to say nearly everyone.

A scheduled pause does not make bugs wait their turn. Attackers do not check the project calendar. If a vulnerability is exploitable in July, it is exploitable whether or not the inbox is open. The pause does not reduce the attack surface. It reduces the project’s ability to learn about what is already exposed.

The precedent is the part to watch

curl runs one of the better security programs in open source. It is a CVE Numbering Authority, it ships clear advisories, it pays bounties, and Stenberg writes about the process in public more honestly than most paid vendors. If that program has to shut its intake for a month to survive automated noise, every smaller project is watching.

Consider the maintainer with one library, ten thousand downstream users, and a Gmail address for security mail. They see curl, the gold standard, close the door. The lesson they take is not “ignore security.” The lesson is “the volunteer intake model is buckling under machine-generated load, and even the best-run project blinked.” That signal travels.

The pause itself is the responsible version of a bad situation. curl announced it in advance, time-boxed it to a single month, and named when intake reopens. That is a planned maintenance window, not an abdication. Compare it to the far more common failure, where a project stops answering security mail with no notice and no end date, and researchers learn through silence that nobody is home. Transparency is the line between a pause and a collapse, and curl stayed on the right side of it.

The worry is the projects that copy the headline without copying the discipline. A month-long, announced, reopening pause is a management decision. An unannounced, indefinite, silent one is how a critical dependency becomes an unmaintained liability that still ships in your build.

If you ship curl, and you do, here is what to actually do

Stop treating the disclosure channel as someone else’s problem and plan around the window.

Know where libcurl lives. Generate a software bill of materials for anything you ship or operate. curl hides inside language runtimes, container base images, and vendored dependencies you forgot you pulled in. You cannot react to a curl advisory if you do not know your own exposure.

Pin your versions and watch the source. The curl security advisory page and the curl-announce list are where real fixes appear. Subscribe to those directly rather than waiting for a downstream distro to repackage the news.

Adjust your patch calendar. Expect no new curl CVE triage during the July window and plan your own response capacity for August, when the backlog clears. If you run anything internet-facing on libcurl, that is the month to have your own monitoring tight, because the upstream early-warning system is dimmed.

If you run your own disclosure intake, learn the real lesson. Add friction that costs the sender, not the triager. Require a reproducible proof of concept before a human reviews a report. Build a reputation gate so first-time submitters clear a higher bar. Use automated pre-screening to filter obvious fiction, applied carefully so it does not bin the rare real bug. The goal is to move the cost back onto the side generating the volume.

The barrier that protected disclosure is gone

The whole responsible disclosure system rested on an unstated assumption: producing something that looked like a credible security report required enough effort to keep the channel mostly signal. That barrier held for two decades. It is gone, and it is not coming back.

Two paths remain. Either intake grows a real cost on the sender side, through proof-of-concept requirements, reputation systems, and paid triage that scales with the noise, or maintainers keep a kill switch they can throw when the firehose overwhelms them. curl just demonstrated the kill switch in public, on purpose, with a date attached.

Watch what reopens in August, and watch what the next ten projects do when their own inboxes fill with confident, well-formatted, entirely fictional bugs. That is where you will see whether the disclosure model adapts or whether the closed window becomes the default.

Share

Keep Reading

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.