Do minor curl vulnerabilities in the open

The curl project has decided to alter its vulnerability disclosure program procedure and starting October 26 2026, we insist that all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository. Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker. Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH. Issues submitted to HackerOne we deem are LOW or MEDIUM will be requested to be resubmitted on GitHub and will be closed as informative on HackerOne (and publicly disclosed).

curl 项目已决定更改其漏洞披露程序。自 2026 年 10 月 26 日起，我们要求所有被认定为“低”（LOW）或“中”（MEDIUM）严重程度的漏洞报告，应改为在我们的 GitHub 仓库中以议题（issue）形式提交。只有被认定为“高”（HIGH）或“严重”（CRITICAL）的漏洞才会保留在 HackerOne 追踪器中进行私密处理。安全研究人员如有疑问，仍可将问题提交至 HackerOne，由我们来判定其严重程度。过去几年中，超过 90% 的提交内容都能被迅速评估为低于“高”级别。对于提交至 HackerOne 并被我们认定为“低”或“中”级别的问题，我们将要求其在 GitHub 上重新提交，并在 HackerOne 上将其关闭为“信息性”（informative）状态（并公开披露）。

Avalanche survival tricks This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown.

雪崩生存技巧：此次政策变更完全是由当前不断涌入的漏洞报告“雪崩”所触发的。我们看不到这些报告的尽头，也不预计在未来几个月内这种洪流会有所减少。作为一个项目，我们正处于挣扎之中，所有核心维护者都感到压力巨大、不堪重负，已接近我们所能承受的极限。为了生存，我们必须采取行动。这是我们生存策略的下一步，可能也不会是最后一步。我们的目标是不被淹没。

Public vs private By opening up the process we allow the whole world to participate. Both in the assessment and understanding of the report and claimed vulnerability, but also in the creating and writing the advisory and figuring out details of when the issues was introduced etc. Ideally we get better help to make sure the fix is the correct one, that it fixes the problem, and any other related problem that is similar and that it does not miss a related problem sitting next to this. An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes. By taking this process to the public all the way, ideally we get more help to do that scrutiny better before we ship releases. We recognize that the amount of work needed per received vulnerability report does not shrink by doing them in public, but we think that we might share the burden among more people easier, and we hope that lessons and documentation brought up in these discussions will be easier to spot and learn from. The open process can also allow distros and other users of curl to keep up with security fixes earlier and better.

公开与私密：通过开放流程，我们允许全世界参与其中。这不仅包括对报告和声称的漏洞进行评估与理解，还包括创建和编写公告，以及查明问题引入的时间等细节。理想情况下，我们能获得更好的帮助，以确保修复方案是正确的，既能解决问题，也能解决任何其他类似的关联问题，且不会遗漏与之相邻的相关问题。最近一个明显的趋势是，当我们宣布一组新的 CVE 及其相关修复方案时，会有一群使用 AI 的研究人员将这些信息投入到他们的模型和测试工具中，以寻找修复方案中类似的错误或疏漏。通过将整个流程公开，理想情况下，我们能在发布版本之前获得更多帮助，从而更好地进行审查。我们认识到，公开处理并不会减少每个漏洞报告所需的工作量，但我们认为这样可以更容易地在更多人之间分担负担，我们也希望这些讨论中产生的经验教训和文档能更容易被发现和学习。开放流程还可以让发行版和其他 curl 用户更早、更好地跟进安全修复。

The risks Several people have suggested there is a risk that researchers mistakenly submit severity HIGH issues on GitHub thinking they are LOW or MEDIUM. It is basically unheard of that a researcher would have understated a reported problem so I consider that a low risk scenario. Also: there was already before this a risk that someone would submit a vulnerability report in the public, it is not a new risk. Handling some vulnerabilities in the public of course makes the immediately available for both good and bad people. This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users. That is unfortunate but we see no way of avoiding this. We limit this practice to less than HIGH for this reason: at least these problems are not terrible.

风险：一些人提出，研究人员可能会误以为严重程度为“高”的问题是“低”或“中”，从而错误地将其提交到 GitHub。研究人员低估所报告问题的严重性几乎闻所未闻，所以我认为这是一种低风险情况。此外，在此之前，也已经存在有人在公共场合提交漏洞报告的风险，这并非新风险。当然，公开处理某些漏洞会使其立即对好人和坏人都可见。这项政策会给坏人提供稍长一点的机会窗口来利用漏洞，从而损害现有 curl 用户的利益。这很不幸，但我们看不到避免这种情况的方法。我们出于这个原因将此做法限制在“高”级别以下：至少这些问题并不严重。

Severity LOW We have discussed simply dismissing all severity LOW issues, but within the CVE program there is an appeals process and if we don’t hand out a CVE to an actual vulnerability, then someone else will do it. We thus cannot ignore true vulnerabilities, or they will come back to bite us nonetheless. We can however resist and refuse silliness and I personally aim to deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users or existing applications.

“低”严重程度：我们曾讨论过直接驳回所有“低”严重程度的问题，但在 CVE 项目中存在申诉流程，如果我们不对实际漏洞分配 CVE，其他人也会这样做。因此，我们不能忽视真正的漏洞，否则它们最终还是会反噬我们。然而，我们可以抵制并拒绝无意义的报告，我个人旨在更强硬地拒绝那些实际上并未伤害任何用户或现有应用程序的漏洞报告。

Crazy combos A clear trend these days is that many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected, but the sequence is something that aren’t likely to ever be used in the real world, or the unexpected that happens is something that occurs every time so applications doing this would spot the problem immediately. I.e problems that have almost no risk to actually trigger in the real world. We save no users by insisting on doing the CVE dance for those issues. We only get work for ourselves and a whole world that has to act on them.

疯狂的组合：如今一个明显的趋势是，许多新报告的漏洞是由 AI 模型发现的，它们创建了疯狂的序列或选项组合，从而导致一些意想不到的行为。但这些序列在现实世界中几乎不可能被使用，或者所发生的意外情况每次都会出现，因此执行此操作的应用程序会立即发现问题。也就是说，这些问题在现实世界中几乎没有触发风险。坚持为这些问题进行 CVE 的“舞蹈”并不能保护任何用户，只会增加我们自己的工作量，并让全世界不得不为此采取行动。

Flow control it There is an almost infinite number of combinations you can use libcurl’s many options, protocol mixes and flexible API to do things that might not be clearly documented and the AIs will continue to try them all and together with the humans driving these checks they are super eager to treat every minor discrepancy as a vulnerability. We can’t continue down this spiraling path with our sanity intact. We don’t have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way.

流程控制：你可以使用 libcurl 的众多选项、协议组合和灵活的 API 进行几乎无限种组合，以实现一些可能未被明确记录的功能。AI 将继续尝试所有这些组合，加上驱动这些检查的人类，他们非常热衷于将每一个微小的差异都视为漏洞。我们无法在保持理智的情况下继续沿着这条螺旋式下降的道路走下去。我们没有带宽、人力，甚至没有意愿以这种速度处理永无止境的漏洞报告流。我相信很少有软件项目能长期承受这种高强度的持续冲击。必须做出改变。

How to assign severity We only use these for levels in the curl project: LOW, MEDIUM, HIGH and CRITICAL. Often we refer back to recently managed vulnerabilities to see how we judged them, but we also provide a set of basic guidelines. I’m sure we can also make them better and clearer.

如何分配严重程度：在 curl 项目中，我们仅使用以下级别：低（LOW）、中（MEDIUM）、高（HIGH）和严重（CRITICAL）。我们经常参考最近处理的漏洞来查看我们是如何判断它们的，但我们也提供了一套基本准则。我相信我们还可以使这些准则变得更好、更清晰。