Curl Pauses Vulnerability Report Intake for July 2026
The project's HackerOne form and security inbox go dark for a month, pushing coordinated disclosure plans into August.
For one month next summer, the world's most ubiquitous HTTP client will stop listening for security reports. The curl project has announced what it calls the "summer of bliss": a deliberate blackout window during which no vulnerability reports will be accepted, triaged, or acted upon.
If you ship software that links against libcurl — which is to say, a large fraction of everything — this is a scheduling detail worth marking in your calendar.
The blackout window, precisely
The parameters are unambiguous:
- Submissions pause: July 1, 2026, 00:00 CEST
- Submissions resume: August 3, 2026, 09:00 CEST (a Monday)
- The HackerOne submission form is simply turned off for the duration.
- The project's security email address becomes, in its own words, "a dead end" — reports sent there will not be processed or cared about.
Worth underlining for anyone tempted to route around the closed form: curl does not accept vulnerability reports over email under normal conditions either, and that policy holds during and after the break. HackerOne is the only sanctioned channel, and it's the channel going dark.
The project's public GitHub issue and pull-request trackers stay open and active as usual. That distinction matters — ordinary bug reports and patches continue to flow; it is specifically the security disclosure pipeline that closes.
What spills over
A month of deferred triage has knock-on effects, and the project is upfront about one of them. The 8.22.0 release, originally on the project's eight-week cadence, slips two weeks to September 2, 2026. The stated reason is to give maintainers breathing room in early August to work through whatever queued up while the form was off.
The arithmetic here is honest about how coordinated disclosure actually works. A vulnerability found on, say, July 10 cannot even be reported until August 3, then has to be triaged, confirmed, fixed, and bundled into a release. Anything that lands in that window realistically waits until the September cycle unless it's severe enough to warrant an out-of-band fix.
Maintainer Daniel Stenberg frames the pause as exactly what it sounds like — a vacation. The team plans to "take in some extra air," fix bugs, write new code, and, in his words, stop programming for a while. He explicitly encourages other open source maintainers to do the same and prioritize their own sanity.
Why a project this critical can step back
Curl says it has been under "huge pressure for the last four months or so" and does not expect the deluge to abate. The post doesn't itemize the cause, so treat any specific attribution as background rather than fact — but curl's maintainers have for some time been publicly vocal about a rising tide of low-quality and AI-generated security reports clogging their HackerOne queue, the kind that look plausible, cite no reproducible bug, and cost real human hours to refute. That context makes a scheduled intake freeze read less like negligence and more like load-shedding.
The deeper issue is structural. Curl is maintained by a small core team yet sits in the dependency graph of an enormous slice of production software. Coordinated disclosure assumes a responsive human on the receiving end, and that human is a scarce, unpaid-or-underpaid resource. A maintainer choosing to throttle inbound load is the system behaving as designed under unsustainable demand — not a failure of it.
Stenberg addresses the obvious objection directly. The bad guys won't rest — probably not, he concedes — but we will. And if something genuinely catastrophic surfaces in July? "Then we get to read about it in August." The one carve-out: organizations with paid support contracts continue to receive full service throughout, including earlier notification of emergencies. That is the lever for anyone who can't tolerate the gap.
What teams should actually do
The practical takeaways are small but concrete:
- Mark the window. July 1 – August 3, 2026, curl's disclosure channels are closed. Plan any coordinated disclosure involving curl or libcurl around it.
- Don't fall back to email. It won't be read, and it isn't a supported channel regardless.
- Expect the September release. 8.22.0 is now slated for September 2, 2026; any fixes for issues reported post-blackout will likely target that cycle or later.
- If you need a guarantee, pay for it. A commercial support contract is the only mechanism that keeps the emergency line open during the pause.
- Hold your finding responsibly. A vulnerability discovered in July should sit until August 3 rather than going public — the disclosure window simply shifts, it doesn't disappear.
There's a broader signal here too. Stenberg's open invitation for other maintainers to declare their own "summer of bliss" reframes a one-project quirk as a norm worth spreading: critical infrastructure run by humans needs slack built into it, and the security community downstream has to plan around the people, not just the code.
Sources & further reading
- Curl will not accept vulnerability reports during July 2026 — daniel.haxx.se
Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.
Discussion 2
i'm a bit concerned about the potential second-order effects of this blackout window - will researchers just sit on their findings for a month or might we see some unofficial disclosures or even exploits in the wild during that time?
i remember when the openssl project did something similar back in the day, just a heads up to everyone: plan ahead and don't let this blackout window catch you off guard, especially if you're working with tight release schedules 📅
