curl is going to handle non-serious security bugs in public. From 26 October, anything the project classifies as low or medium severity gets reported in its GitHub repository, where anyone can read it. The private channel is reserved for high and critical. Daniel Stenberg announced it, and the reason he gives isn't philosophical: they're swamped.
What happened
Stenberg talks about an avalanche of vulnerability reports that doesn't stop, that they don't expect to ease off for months, and that has every key maintainer at the limit. His words, and they're not the kind you write lightly:
We must act to survive. This is our next step in a survival strategy. It might not be our last.
The numbers explain the decision better than any manifesto: over the last few years, more than 90% of submissions could be quickly assessed as below HIGH. Nine out of ten reports burn the project's most expensive resource — the attention of a handful of people — only to land in the drawer marked "minor".
This isn't the first move. Earlier this year they shut down the bug bounty, because AI-generated submissions were piling work onto the security team. Stenberg has said more than once that not every AI-assisted report is rubbish, and he stands by it. But he describes a very specific pattern: people using a model to generate wildly unusual option combinations that would never occur in a real application, then presenting any minor discrepancy as a vulnerability.
Anyone unsure how serious their finding is can still submit through HackerOne and the project will tell them which drawer it goes in. What changes is the default destination for the small stuff. The project's security policy lives, as always, in curl's documentation.
Why it matters
The interesting part isn't curl. It's the asymmetry.
Producing a plausible vulnerability report now takes thirty seconds and pennies. Assessing one costs whatever it costs: read the code, reproduce it, work out whether that option combination exists in the real world, write the reply. A solid hour from someone who knows. When the cost of producing collapses and the cost of verifying doesn't budge, the system breaks on the verifier's side. Every time. We saw it with email, with blog comments, with app stores — and now it's the turn of security triage for the software that runs your car, your router and half your containers.
If you maintain an open source project, the practical reading is that the private security inbox has stopped being free. It was a reasonable courtesy when five reports arrived a month. At two hundred, it's a channel that forces you to reply privately, on a deadline, carefully, with nobody else able to help. Opening it up for the small stuff is, literally, sharing the load: more eyes assessing, more people writing the fix, a better chance someone spots a related problem before the next release ships.
And if you merely consume curl — which you almost certainly do, because we all do — there's an operational consequence from 26 October: some of what used to reach you as a tidy advisory now lives in a public issue. The severity the project assigns is the severity for the project. A "low" in curl can be a "high" in your particular setup, with your options and your exposed surface. You've always had to do that translation yourself; it just wasn't visible until now.
What doesn't change
Stenberg is honest about the limits, and they're worth repeating. Handling a report in public does not reduce the work per report: it spreads it, and it makes the resulting lessons and documentation easier to find afterwards. In theory. His word, not mine.
The big downside is the other one: publishing before the fix exists hands attackers a window. That's precisely why the measure stops below HIGH — these are problems that, as he puts it, at least aren't terrible. It's an accepted toll, not an oversight.
Nor is this the end of open source, or "AI broke curl". Plenty of projects have discussed their minor bugs in the open forever; curl was the odd one out for running almost everything through a private channel. What changed isn't the model, it's the volume.
Our take
I think it's the right call, and I think it's late. But what I'm applauding isn't the transparency: it's the change in incentives.
Sending a weak report to a private inbox costs you nothing. Your name doesn't show, your dud doesn't show, and if it sticks you get the credit. Sending it to a public issue has a price: it's written down, with your handle next to it, and anyone can see that what you brought is a lab curiosity that happens to nobody. That filters. Not through censorship — through embarrassment, which is the mechanism that has held open source together from day one.
Where I think this ages badly is the sharing part. The "more eyes" promise works when there's a community looking, and curl has one. On a two-person project, opening up triage shares nothing: it just adds managing a public thread on top of the work you already had. If the avalanche keeps up — and Stenberg says he sees no end — the next step won't be more transparency, it'll be a barrier to entry: prior reputation, a deposit, invitations only. I'd bet we see it at a major project within a year, and there'll be an outcry nobody remembers six months later.
One more thing, for anyone running a team who doesn't maintain anything open: this is already arriving in your corporate security inbox. Immaculately formatted reports, generated in bulk, about things that don't affect you. The answer isn't hiring someone to read them all; it's deciding in advance what matters to you and writing down the cases where you don't even reply.
When we set up vulnerability monitoring for a client, the work is never in receiving the alert: it's in deciding whether it actually affects them given the version and configuration they're running. Nobody automates that step yet, and it's the one that eats the hours.
The original story, at The Register.
Any questions, tell me and we'll go through it.
All the best, Vicente.