Today, Daniel Stenberg — the creator and lead maintainer of curl — announced that the curl project will not accept any vulnerability reports during the entire month of July 2026.
Not "we're slow." Not "please be patient." Not accepting them at all.
The HackerOne form closes July 1. The security email goes dark. If you find a zero-day in one of the most widely deployed pieces of software on Earth — a tool installed on an estimated 30 billion devices — you will have to wait until August 3.
This is not a scandal. This is a distress signal. And if you're a developer, it deserves your full attention.
First, some context on what curl actually is
curl is that command-line tool you use to fetch a URL. It's also libcurl, the C library that powers HTTP, HTTPS, FTP, SMTP, SFTP, and about 25 other protocols inside software you use every day. It's in your phone, your smart TV, your car's infotainment system, your streaming service, your bank's backend. It's in cloud infrastructure. It's in NASA satellites.
Daniel Stenberg has been working on it for almost 30 years. Since 2019, he has done it full-time — typically clocking 50-hour weeks, evenings included.
When this person says "we need a break," something has gone seriously wrong with the system.
What's been happening for the last four months
In May 2026, Stenberg posted an unusually candid piece called "The Pressure." It described a situation that had crossed from "busy" into something harder to name.
The rate of incoming security reports was running 4–5 times higher than anything the project had seen in its 28-year history.
This isn't because curl suddenly became insecure. It's because of two converging forces:
1. AI-generated vulnerability reports flooded in at scale.
Starting in mid-2024, security researchers began weaponizing LLMs to generate CVE submissions. An LLM can read source code, pattern-match against known vulnerability classes, and produce a convincing-sounding security report in seconds. The reports are sometimes real. More often, they're plausible-sounding noise that still requires a human expert to evaluate.
Stenberg has been writing about this for over two years. In January 2024 he described "stupid LLMs" submitting junk. By July 2025 it was "death by a thousand slops." By January 2026, curl closed its bug bounty entirely — the incentive program that paid researchers for finding real bugs — because the ratio of signal to slop had collapsed.
2. A serious security auditing firm genuinely started scanning curl.
In spring 2026, a company called Mythos ran an AI-powered security audit on curl. They found one low-severity issue. But the announcement triggered a second wave: other security firms, researchers, and automated tools piling on to "also audit curl" — some legitimate, most noise.
The result: even the high-quality reports required exhausting expert attention. Every report, real or AI-slop, demands triage. Most cannot be dismissed without careful analysis. You cannot rubber-stamp a potential curl vulnerability with "probably fine."
The math of maintaining a critical piece of infrastructure
Here's the part developers often miss: curl's security track record is exceptional because of relentless attention. It is one of the most fuzzed, most reviewed, most tested codebases in existence. That isn't luck. That's decades of unglamorous work.
But "highly scrutinized" cuts both ways. The better your track record, the more attention you attract. The more attention you attract, the more reports you receive. The more reports you receive, the more human expert hours you burn. And the number of humans who can meaningfully review curl security vulnerabilities — who know the codebase deeply enough, who understand the protocol interactions, who can distinguish a real issue from a hallucinated one — is tiny.
Stenberg made an observation in May that stuck with me:
"I am jealous of those projects that shipped a horrible bug at some point in the past that made the world burn for a while. They got attention and some of them then got funding... I sometimes think we would be better off if we also had one of those."
He's talking about how OpenSSL only got real resources after Heartbleed (2014). Log4Shell brought Log4j into the spotlight. The way critical open source infrastructure gets funded is often through catastrophe — not through sustained, excellent, prevention-first work.
curl has never had its catastrophe. It has maintained its quality largely through one person's obsession. And that person needs a month off.
What this means if you depend on curl
Which, practically speaking, is everyone.
The immediate practical answer is: probably nothing dramatic.
curl is not going unpatched for a month. The GitHub issue tracker stays open. Development continues. If a critical zero-day emerges and becomes actively exploited, the team isn't going to ignore it forever — paid support contracts remain active, and critical situations have their own escalation paths.
The July window is specifically about new incoming reports — not about existing known issues or active exploits.
But the larger message is more uncomfortable.
You are running software built on infrastructure maintained by a handful of people who are burning out. This is not unique to curl. The same pattern exists across:
- OpenSSL (critical in every TLS connection you make)
- zlib (compression inside almost everything)
- GNU libc (used by nearly all Linux software)
- ImageMagick (image processing across the web)
- Bash (present on essentially every Unix system)
- Hundreds of npm, pip, and Cargo packages with millions of downloads and single-digit maintainers
The security model that most developers implicitly rely on — "smart people are watching this and will catch problems" — depends on those smart people having the time and energy to do the watching.
The AI vulnerability report problem is structural
This deserves more attention than it's getting.
The widespread availability of code-auditing LLMs has fundamentally changed the economics of vulnerability reporting. Before, submitting a convincing bug report required expertise. That expertise was a rate-limiter — it meant only a small number of humans could generate reports per day.
LLMs removed that rate limiter. Now, a person with no security background can point a tool at a codebase and receive 50 plausible-sounding vulnerability reports in minutes. The cost to submit a report approaches zero. The cost to evaluate a report has not changed — it still requires deep human expertise.
This is a classic case of asymmetric economics. The attacking side (report generation) gets cheaper and faster. The defending side (expert triage) doesn't scale.
For curl specifically, Stenberg closed the bug bounty because the financial incentive was making the signal/noise problem worse, not better. The people generating AI slop reports were doing it for the bounty. Remove the bounty, remove one incentive. But the reports kept coming anyway — because now there are security firms whose business model is "we scan your codebase with AI," and curl is a prestigious target.
What you can actually do
As a developer consuming open source:
Check if your critical dependencies have active maintenance. Look at the GitHub contributor graphs. Look at who's responding to issues. Look at when the last release was. Don't assume "popular" means "maintained."
Support maintainers financially if you can. Daniel Stenberg has a GitHub Sponsors page. Curl has a support contract model for organizations. If your company ships products that include curl — which it almost certainly does — paying for a support contract isn't charity. It's supply chain security.
Don't use AI tools to bulk-generate CVE reports. Seriously. The people who will triage those reports are the same people keeping the software secure. You're consuming their attention.
Read the
SECURITY.mdbefore reporting. Most projects have written clear guidelines on what constitutes a valid report, what information to include, and what channels to use. An ignored AI-generated report helps nobody.
As someone who builds software that others depend on:
The curl situation is a useful mirror. Burnout in maintainers is a security risk, not just a management problem. A burned-out maintainer misses bugs. A burned-out maintainer may abandon a project. A burned-out maintainer may make the error that becomes the next Heartbleed.
Build your sustainability model before you need it, not after.
The broader context: open source needs a different funding model
This has been said before, but it's worth repeating in this specific context.
The open source ecosystem has a free-rider problem at scale. Software infrastructure worth billions of dollars in economic value — enabling trillion-dollar cloud markets — is maintained by small teams of dedicated people, often for free or for compensation that doesn't reflect the value they produce.
Various attempts have been made to fix this:
- Bug bounties (worked until AI slop destroyed the signal-to-noise ratio)
- Foundation funding (Apache, Linux Foundation — helps large projects, not the long tail)
- GitHub Sponsors / Open Collective (useful but relies on individual altruism)
- Corporate contributions (Google, Microsoft, Meta contribute to some projects; most don't)
The EU's Cyber Resilience Act is pushing some changes — requiring organizations that ship products with open source components to contribute back in some way. But enforcement and implementation are years out, and curl won't get a break for it.
For now, the curl Summer of Bliss is what it is: a small team of exceptional engineers saying "we're going to take July off, and the world will need to live with that."
The honest response isn't panic. It's recognition that this situation — one person's sustained effort keeping critical infrastructure secure for 30 billion devices — is not stable, and the industry has been relying on it without acknowledgment for decades.
Wrapping up
curl is pausing vulnerability intake for July. Nothing will probably break. The software isn't going to suddenly become unsafe on July 1.
But if you're a developer and this surprised you — if you'd never thought about who maintains the libraries you depend on, or how sustainable that is — maybe spend an afternoon looking at your dependency tree from that angle.
The tools you use every day were built by humans. Those humans need time to breathe.
Gerus-lab builds custom software solutions and AI integrations. If you're curious about our work, visit gerus-lab.com.
Top comments (0)