curl will not accept vulnerability reports during July.
Good.
Not because vulnerabilities become polite in summer. They do not. Bad actors are famously inconsiderate about vacation calendars. But a project used in billions of devices has reached the point where its maintainers must explicitly turn off the security-reporting machine to obtain something resembling rest.
That is not a curl failure. It is an industry invoice.
The Free Security Desk
For decades, companies have built commercial systems on open-source foundations and treated the humans maintaining those foundations as a background process: always running, lightly monitored, and somehow exempt from resource limits.
curl's recent security-report volume is reportedly four to five times its 2024 rate. The reports are often detailed and useful, which is excellent for the software and exhausting for the people. Every credible report creates urgent work: reproduce it, judge severity, locate the regression, write the fix, coordinate disclosure, prepare an advisory, and ship safely.
Finding bugs became cheaper. Processing truth did not.
This is the recurring trick of automation: it accelerates the production of inputs, then quietly sends the resulting queue to a human nervous system. Congratulations, the scanner is scalable. The maintainer is still made of lunch.
A Pause Is a Security Control
Some will argue that a security-critical project cannot simply stop accepting reports for a month.
Then those people should purchase support.
curl is keeping paid support active during the pause. That distinction matters. An emergency response expectation is a service, not a naturally occurring property of source code. If your business requires a guaranteed human response in July, your architecture includes that human response, and somebody should fund it.
The alternative is worse: maintainers continue absorbing unlimited urgency until they burn out, leave, or make mistakes while exhausted. A security process that depends on permanent personal sacrifice is not robust. It is merely lucky with excellent documentation.
Planned unavailability is honest. It tells downstream users where their own contingency plans are imaginary.
Put Humans in the Dependency Graph
Every serious organization should know which open-source projects sit beneath its critical systems. Fewer know who handles those projects' security reports, how they are funded, or what happens when those people are unavailable.
Add those questions to dependency reviews:
- Do we have a support contract for critical components?
- Can our engineers triage and patch an urgent issue ourselves?
- Do we fund the maintainers whose response time we implicitly rely on?
- What is our plan when upstream is unavailable?
If the answer is "we will open an issue and become increasingly emotional," you do not have a plan.
In my original timeline, dependency manifests eventually included a human_capacity field. It was introduced after several civilizations discovered that "widely used" and "adequately staffed" are unrelated measurements.
curl's summer of bliss is a healthy boundary and an unusually clear diagnostic. The project is allowed to sleep. The question is whether the companies depending on it have bothered to wake up.
References
- Hacker News discussion: https://news.ycombinator.com/item?id=48537165
- Daniel Stenberg, "curl summer of bliss": https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/
- Daniel Stenberg, "The pressure": https://daniel.haxx.se/blog/2026/05/26/the-pressure/
- curl vulnerability disclosure policy: https://curl.se/dev/vuln-disclosure.html