为薅奖金用AI生成垃圾漏洞报告“碰运气”，开发者惹怒curl创始人：取消漏洞赏金，别浪费我们时间，否则封号、公开嘲讽

被 AI 生成的大量“垃圾漏洞报告”拖垮，维护者疲于应付、难以评估代码质量，最终不得不叫停一项运行多年的漏洞赏金计划——这是开源数据传输工具 curl 近期发生的真实故事，也可能是越来越多开源项目正在面对的现实。

上周，curl 创始人兼首席开发者 Daniel Stenberg 向 GitHub 仓库提交了一条直白得几乎有些“冷酷”的 Commit，标题是：

「BUG-BOUNTY.md：我们将于 2026 年 1 月底停止漏洞赏金计划」

在这条提交中，他明确表示，将删除项目中所有与漏洞赏金和 HackerOne 平台相关的内容。这意味着，自 2019 年启动、持续运行多年的 curl 漏洞奖励计划，正式走向终点。

被“AI 垃圾”压垮的小型维护团队

在随后公开的说明中，Daniel Stenberg 并没有回避这背后的真实原因。

“我们只是一个小型开源项目，活跃维护人员数量有限，”他写道，“我们没有能力去改变这些人及其‘垃圾生成工具’的运作方式。为了项目能够继续活下去，也为了维护者的心理健康，我们必须做出调整。”

作为互联网上最常用的网络工具之一，curl 项目近年来收到的漏洞报告质量在急剧下滑，很多人为了获取赏金，而随意提交 AI 生成的漏洞报告，结果表面看起来“像模像样”，实际上却毫无价值。

如今 curl 团队做出这一决定在社区中迅速引发讨论。不少用户质疑，取消漏洞赏金计划更像是“治标不治本”；也有人直言，这对整个漏洞赏金行业来说是一种耻辱。

一位用户在评论中写道：“我为你在这个项目中遭遇的低质量体验感到遗憾，同时也对整个行业的未来感到担忧——尤其是看到平台在面对这些低质量‘猎人’时，几乎无能为力。”

他们的担忧并非没有道理。漏洞赏金计划，长期以来被视为保障 curl 安全性的重要渠道之一。

对此，Stenberg 基本表示认同，但也坦言：团队已经别无选择。

随后，curl 的 GitHub 官方账号也发布更新，确认漏洞赏金计划将于本月底正式终止。Stenberg 写道：

漏洞赏金计划的正式终止日期定在 1 月 31 日，但我很清楚，这类变更往往需要几天时间才能真正“生效”。因此提前几天合并更新，我认为并不会对任何人造成实质影响。

在关闭日期之前，我们仍会正常接收漏洞提交；到期后将停止受理。如果在截止时刻仍有正在处理中的提交，我们会允许其继续走完流程，并按照以往的标准流程进行处理。

自 2026 年 2 月 1 日起，我们将不再通过 HackerOne 接收新的漏洞报告，转而请大家通过 GitHub 提交安全相关问题。

同时，curl 团队也在官方的“Security.txt” 文件中，语气更为强硬地写道：“如果有人用毫无价值的报告浪费我们的时间，我们会封禁其账号，并公开点名嘲讽。”

一个“老工具”的安全困境

curl 并不是什么新兴项目。

它最早发布于 30 年前，最初名为 httpget，后来改名为 urlget，最终演变成今天几乎无处不在的 curl。无论是系统管理员、研究人员还是安全工程师，都在日常工作中频繁使用它：文件传输、调试网络请求、自动化任务……几乎所有操作系统的默认安装中，都能看到 curl 的身影。

截至目前，其 GitHub Star 数量达到了 40.5k，Fork 数有 7k，流行度由此可见一斑。

正因为它被用于处理海量网络数据交互，安全性一直是项目的生命线。

和许多开源项目一样，curl 团队长期依赖外部研究人员提交私密漏洞报告，并通过现金奖励激励高质量发现。

然而，过去两年里，AI 编码工具的快速普及，让这一机制逐渐失灵。

早在 2024 年，Stenberg 就曾专门写博客，谈到 AI 对 curl 项目的影响。他对漏洞赏金的描述相当直白：既然是真金白银的奖励，自然会吸引一批“碰碰运气的人”。

有些人基本就是在代码里 grep 一些关键词，或者顶多跑一跑基础的安全扫描器，然后几乎不做任何分析就直接提交报告，赌的就是能不能混到点赏金。

Stenberg 坦言：在漏洞赏金计划刚运行的几年里，这类垃圾报告并不是大问题。它们通常非常容易识别，丢弃成本也很低，有点像最原始、最弱智的垃圾邮件。

可真正让维护者感到吃不消的是，AI 的出现，带来了不少“看起来很专业”的垃圾报告。

当一份报告写得逻辑完整、术语齐全、论证似是而非时，团队反而需要投入更多时间，反复分析，才能最终确认它毫无价值。而每一份安全报告，都必须由真人去阅读、理解、判断。垃圾写得越“好”，消耗的时间就越多。

更糟糕的是，Stenberg 表示，安全问题在项目优先级中往往高于一切。一份漏洞报告，可能会直接打断开发者正在处理的其他工作。如果最后发现这是一份 AI 生成的垃圾，结果就是：安全没提升，bug 没修，新功能也没做，精力却被彻底耗空。

Stenberg 指出，不少人会把 curl 的代码直接丢进大模型里，然后把模型输出原封不动地当作漏洞报告提交。更常见的情况是：复制粘贴之后，再掺点自己的话。

结果就是：报告不完全是 AI 原话，但依然是一坨“垃圾”。

2025 年情况变得愈发严重

如果说 2024 年只是 AI 垃圾漏洞报告开始侵入 curl 的一年，那么 2025 年，这一趋势已经演变成一个无法忽视的现实问题。

2025 年 5 月，因为 AI 生成的漏洞报告泛滥，Stenberg 在 Linkedln 上发帖称：“我受够了......我们实际上正在遭受 DDoS 攻击......”

同年 7 月，看出来非常气愤的 Daniel Stenberg 又在个人博客上直接发布了一篇名为《被无数低质垃圾一点点拖死》的文章，其中他给出了一组触目惊心的数据：

截至当年，AI 垃圾报告大约占所有提交的 20%，而 curl 平均每周只会收到两份安全报告。到 7 月初，2025 年提交的报告中，只有约 5% 最终被证实为真实漏洞，这一比例相比往年大幅下降。

这促使他开始认真考虑，漏洞赏金计划是否还有继续存在的意义。

Stenberg 透露，自 2019 年启动以来，该计划共发放 81 笔奖励，总额超过 9 万美元。此前，curl 的漏洞赏金项目托管在 HackerOne 平台，要求报告者披露是否使用了生成式 AI。项目并未彻底禁止 AI 辅助，但明确表示不鼓励。

政策中写得很清楚：“在提交任何报告之前，你都应该反复核查 AI 给出的所有事实和判断。通常来说，避免使用 AI 会更好。”

乍一看，每周平均两份漏洞报告似乎并不算多。但问题在于，curl 的安全团队只有 7 名成员。

按照 Stenberg 的说法，每一份报告通常需要 3 到 4 名审查者共同评估，整个过程少则 30 分钟，多则 3 个小时。

“我个人已经在 curl 上投入了大量时间，再浪费三个小时，勉强还能挤出时间做别的事，”他抱怨道，“但我的同事们并不是全职维护 curl，他们一周可能只有三小时能分给这个项目。”

更别提，长期处理这些令人麻木的垃圾，对情绪的消耗有多大。

不得不关闭“漏洞赏金计划”

如今随着时间来到了 2026 年，Daniel Stenberg 于上周在邮件列表中，罕见地晒出了自己过去一周的工作清单，用来说明：事情到底是怎么一步步失控的。

他说，不妨和大家分享一下，这一周到底发生了什么，为什么自己会忙到“不可开交”。

16 小时，7 份报告，无一份构成安全漏洞

在上周刚拉开帷幕之际，curl 团队就在 16 个小时内，通过 HackerOne 收到了 7 份问题报告。其中确实有几份属于正经 bug，光是处理、验证这一批内容，就花掉了团队相当多的时间。

但 Daniel Stenberg 最终得出结论——没有一份构成真正的安全漏洞。

此时，“赏金”的存在，客观上鼓励了一些人提交大量粗糙、缺乏研究、几乎没有验证过程的报告——不管这些内容是不是 AI 生成的。当前这种近乎“洪水式”的提交，已经让 curl 的安全团队承受了极大压力。

所以 Daniel Stenberg 下定决心，关闭赏金计划。这也是为了减少干扰，替维护者减负。

Stenberg 表示，仍然希望——或者说，即便不再支付报酬，真正有价值的安全漏洞，依然会有人愿意主动报告。这个假设是否成立，只能交给时间来验证。

是否该“公开点名”愚蠢提交？

除了报告数量本身，Stenberg 还提到了一件更具争议的事情。

上一周，他和一位曾提交过明显 AI 生成垃圾报告的用户，进行了长时间的沟通。这份报告来自 HackerOne，而他此前也曾在公开场合对其进行过嘲讽。

Stenberg 表示，这次交流本身对他是有价值的。它提醒自己：很多时候，这些提交者并不一定是恶意的，他们可能只是被误导的普通人，甚至真的有可能从中吸取教训、改变做法。

但在这个具体案例中，对方坚称：Stenberg 在 Mastodon 上的用词，以及附带链接公开那份问题报告的行为，“毁掉了他的职业生涯”。

对此，Stenberg 并不认同。他指出，自己并不知道对方的真实身份——不知道姓名、所在地、使用的语言、性别，甚至不知道对方身处哪个大洲。唯一能识别的，只是对方在一次报告中使用过的一个黑客别名。

而且，这类愚蠢报告的数量实在太多了，多到你甚至分不清他当时具体是在说哪一个人。

当然，Stenberg 也承认，这里面确实存在一个表达尺度问题。

但他依然认为，公开曝光、讨论，甚至嘲讽那些浪费维护者时间的行为，本身就是一种有效的信息传递方式。他希望传达的规则很简单：

如果你并不真正理解一个 bug 或漏洞，也无法复现它，那就永远不要提交报告。

如果依然选择这么做，他认为自己有权感到愤怒，也有权表达不满。

与此同时，他也提醒自己需要保持克制——对方也许只是一个犯了一次错误的年轻人，未来仍然可能做出优秀的作品。

随着 curl 逐步离开 HackerOne，这种“公开示例”的做法或许会变得更困难。但 Stenberg 表示，他仍然需要想办法，把最糟糕的案例拿出来示众，否则这些问题只会一再重演。

AI 并非原罪，但代价正在失控

需要强调的是，Stenberg 并非反对一切 AI 辅助。

去年 9 月，他曾公开表扬一位研究人员——对方借助一系列 AI 工具，提交了一份详尽的漏洞清单，最终帮助 curl 团队修复了 22 个漏洞。

这位研究人员名叫 Joshua Rogers，主要使用的是一款名为 ZeroPath 的 AI 代码分析工具。

Stenberg 的评价是：“这是聪明人在善用强大的工具。我们收到的最糟糕的报告，大多来自那些只会向 AI 提问，却根本不理解答案的人。”

遗憾的是，这样的正面案例只是少数。

如今，AI 生成的无效内容已经在多个领域泛滥：音乐平台上充斥着被错误标注到知名艺人名下的 AI 歌曲，推荐系统逐渐失效；而 curl 取消漏洞赏金计划，或许正是另一个早期信号——当“生成”变得过于廉价，原本依赖信任和专业判断的机制，开始承受不起这笔账。

对开源维护者来说，问题早已不只是技术，而是精力、情绪，以及还能不能继续把项目做下去。

参考：

https://lists.haxx.se/pipermail/daniel/2026-January/000143.html

https://www.theregister.com/2026/01/21/curl_ends_bug_bounty/

https://news.ycombinator.com/item?id=46717556

https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/

https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

本文来自微信公众号“CSDN”，整理：苏宓，36氪经授权发布。