一句话总结

该专心写书，还是去追漏洞赏金？

亮点

• 在专注写书和投身安全漏洞赏金之间难以抉择。
• 正在考虑开设一门课程，分享用 AI 挖掘安全漏洞的经验。

目标评分

每个月初，我都会定下当月的目标，以下是完成情况：

完成《Refactoring English》的写作

• 结果：大概还需要 1 到 2 周才能写完
• 评分：C

总觉得快要完成了，却在漏洞赏金上花了比计划多得多的时间。

《Refactoring English》数据

由于自 3 月以来没有做任何推广，图书收入有所下滑。相反，我一直被漏洞赏金挖掘分了心。好在还能靠之前的积累勉强维持，但如果继续忽视推广，数据恐怕会一路跌向零。

三个月的漏洞赏金计划

过去三个月里，我花了大量时间用 AI 来寻找安全漏洞。之所以没有公开谈论，是不想在数量有限的漏洞赏金项目中引来竞争。我不确定其他人是否已经意识到 AI 在安全研究中有多高效，但现在看来这已经不是秘密了。

如果你没有关注 AI 与安全研究的进展，Firefox 就是一个惊人的案例。在整个 2025 年（那时 AI 在安全研究上还派不上什么用场），Mozilla 和外部研究人员加起来每个月在 Firefox 中发现 10 到 20 个安全漏洞。

2026 年 2 月，Anthropic 用 Claude Opus发现了 22 个 Firefox 漏洞。换句话说，仅 Anthropic 一家当月发现的数量，就超过了此前 13 个月中任何一个月所有人发现的总和。两个月后，Anthropic 又用 Claude Mythos 在 Firefox 中多发现了 271 个漏洞。

我算是比较早就察觉到了这一趋势，但判断稍有偏差。早在 1 月，我就觉得 AI 可能会彻底改变网络安全研究，但我以为价值在于打造安全工具。当时我用 AI 编写模糊测试工具，惊讶地发现模糊测试的效率远比手动操作时高得多。

尽管用 AI 写模糊测试器的速度能提升 10 到 20 倍，事后却发现这条路远比必要的工作量更繁重。与其让 AI 生成模糊测试工具再去分析输出，不如直接让 AI“看看源代码，把所有漏洞都找出来。”

在见识到 AI 直接审计源代码的能力后，我就不再做模糊测试，转而专注于源码审计。到目前为止，我已向五个不同的漏洞赏金项目提交了 50 多个漏洞，获得了约 1 万美元的奖金。

漏洞越来越好找，赏金却越来越难拿

虽然用 AI 找安全漏洞颇有成效，但在找到愿意为此付费的公司方面，却不那么顺利。

目前的结果如下：

• 厂商 1：Meta
  • 提交了 8 份报告，其中包括一个远程代码执行漏洞。
  • 数周没有收到任何回复。
  • 我找到了负责该产品的开发者的邮箱并联系了他们，他们帮忙将报告推进到了初审之后，但此后又陷入停滞（已经两周多没有进展）。
• 厂商 2
  • 提交了 1 份报告。
  • 对方在 1 个工作日内完成了初审，但表示需要数周时间才能深入调查。
  • 已有 30 多天没有收到任何消息。
• 厂商 3：
  • 提交了 1 份报告。
  • 对方称是重复提交，因此没有奖金。
• 厂商 4
  • 提交了约 40 份报告。
  • 其中 8 份在两周后获得了奖金，共计 9,700 美元。
  • 2 份被判定为重复而驳回。
  • 其余的都在等待初审，不过最有价值的几份已经包含在获得奖金的前 8 份中。
• 厂商 5：Firedancer（加密项目）
  • 发现了几个中等严重程度的问题。
  • 开始走赏金申报流程时，发现他们要求研究人员向一个我从未听说过的服务上传护照，于是就此作罢。
  • 他们的项目规则也很含糊，似乎与所使用赏金平台的规则相矛盾。

所以，来自厂商 4 的 1 万美元只花了两周的兼职时间。如果不是还在另外几个毫无回报的赏金项目上花了 6 周多时间，这笔投入产出比会非常可观。如果能找到更多像厂商 4 这样的项目就好了，可我不知道该怎么做。

该专注于写书，还是漏洞赏金？

现在，我在写书和漏洞赏金之间难以分配时间，想法如下：

• 专注于写书
  • 优点：书已经接近完成，如果集中精力收尾，它将比半成品更有价值。
  • 优点：这本书只有我能写出来，而参与漏洞赏金的人有很多。
  • 优点：交付已经延期，完成它能减轻让读者等待的愧疚感。
  • 优点：我可以公开谈论写作过程，这不仅有助于自己理清思路，也能让更多新读者发现这本书。
  • 缺点：至少在短期内，写书的预期收益似乎低于挖漏洞。理论上，下周就可能发现一个价值 10 万美元的漏洞，而下周让图书多卖 10 万美元的可能性却微乎其微。
• 专注于漏洞赏金
  • 优点：两周漏洞赏金的收入就超过了 2025 年全年图书的收入。
  • 优点：仍有大量尚未被发现、且能用 AI 工具找到的可获赏漏洞。
  • 优点：如果暂停几个月，剩余漏洞的价值会大幅缩水，因为其他研究人员会抢先拿下那些容易发现的漏洞。
  • 缺点：参与漏洞赏金令人沮丧，因为你毫无议价能力。厂商完全可以压价甚至赖账，而你几乎没有追索或谈判的筹码，除非把漏洞卖给想用于作恶的买家。
  • 缺点：漏洞赏金像赌博一样容易上瘾，因为它带有不确定的回报，时不时随机出现。
  • 缺点：漏洞赏金让我重陷不良的 AI 使用习惯。如果有一个 AI 智能体在后台扫漏洞，我就会忍不住不断查看进度，并根据早期结果反复调整方向。
  • 缺点：我在公开分享工作内容方面受到更多限制，一方面是赏金项目本身的要求，另一方面也不想把竞争对手吸引到我正在投入的地方。

从理性上看，我很难为继续追逐漏洞赏金找到充分理由，但还是想稍微坚持一下，或许按 70/30 的比例在写书和漏洞赏金之间分配时间。

或许我该教大家用 AI 提升软件安全性

第三种可能是，与其追逐赏金，不如把过去几个月里学到的用 AI 挖掘安全漏洞的经验教给别人。

我在考虑开设一个小规模的、按期进行的课程，大家一起在开源项目中找漏洞。我们会挑选没有关联赏金的项目，这样学员可以在内部共享发现，而不必担心有人抢走奖金。形式将是直播或录播演示加上 2 到 4 周的私密群组交流的组合。

这门课的重点不是靠漏洞赏金赚钱。也许我会涉及一点，但那不会是重点，因为过去三个月里我学到最多的并不是这个。

课程的核心是用 AI 在大型代码库中发现安全漏洞。我会分享如何让 AI 工具聚焦于最可能出现漏洞的区域、避免在无效线索上浪费时间和 token 的技巧。这些方法既可以应用于团队内部的闭源代码，也可以用于你想帮助加固的开源项目。

如果感兴趣，请在下方加入意向名单：

• 意向登记——用 AI 发现安全漏洞

推荐

Timelinize 让你从社交媒体中夺回自己的数据

几周前，我在 reddit 上看到一个提问，有人想删除 Facebook 账号，但又想以可用的格式保存一份数据存档。这让我想起曾在 Hacker News 上看到过但一直没深入了解的项目——Timelinize。

Timelinize 可以导入你从 Facebook、Google、Twitter 等服务导出的数据，并生成一个统一的时间线来浏览这些数据。作者是 Matt Holt，他也是知名反向代理 Caddy 的作者。

Timelinize 目前仍处于早期阶段，我为了让它好用打了不少本地补丁，但我很看好它的方向。之后会随着使用把更多补丁合入上游。

每当找到一个可以用本地离线方案替代云服务的例子，总会感到一种莫名的清爽。当我从流媒体服务转向 Jellyfin 时，就惊讶地发现，仅仅看自己想看的内容、而没有公司在背后盯着你如何变现，感觉是如此不同。

奇怪的是，看 Netflix 或 HBO 时，我从未有意识地想过“糟了，我被监视了”。但当我完全转向本地观看影视后，就好像在一个格子间里待了太久，忘记了外面还有世界。然后走出门，呼吸到新鲜空气、晒到阳光——当然，这只是比喻。实际上我还是坐在屋里用电脑看电视。但那种体验比以前更快、更自由！

用 Timelinize 时也有类似“呼吸新鲜空气”的感觉。Timelinize 的界面以用户为中心，这让我意识到云平台的界面对用户是多么不友好。Facebook 和 Twitter 并不希望你轻松翻阅旧消息，因为那无法为它们赚钱。为了不让你阅读旧消息，它们把体验设计得微妙地令人不适：把对话挤进一个小框里，每隔几秒就让你停下来等待新消息加载，还不断用各种通知把你拉回到能变现的新内容上。

而 Timelinize 的阅读体验就是让你安静地阅读存档。没有任何东西试图分散你的注意力、吸引你去看新内容，因为它展示的是历史快照。我很喜欢跳转到 10 年前的某一天，看看当时的对话是什么样子。

The React2Shell Story and What Happened Next.js

我当时没有关注 React2Shell，它是 React.js 中的一个严重漏洞，攻击者可借此在许多 React.js 和 Next.js 应用中实现代码执行。

上周，发现 React2Shell 的两位研究人员撰文讲述了背后的故事：

• “The React2Shell Story”，作者为发现该漏洞的主要研究人员 Lachlan Davidson。
• “The React2Shell Story and What Happened Next.js”，作者 Sylvie Mayer，她协助 Lachlan 挖掘漏洞、通知厂商并寻找愿意为此付费的漏洞赏金项目。

Lachlan 的文章获得了更多关注，但我觉得 Sylvie 的更有意思，尤其考虑到当时她还只是一名 20 岁的大学生。

Lachlan 和 Sylvie 都意识到他们发现了一颗“核弹”，影响着数百甚至数千个主流网站。在向维护 React 的 Meta 和维护 Next.js 的 Vercel 报告漏洞后，他们想寻找其他愿意为这一重大发现付费的漏洞赏金项目。

在 Meta 公开安全公告之前，研究人员不能向其他厂商披露该漏洞。问题在于，一旦 React2Shell 公开，Lachlan 和 Sylvie 在争抢同一批赏金时就会失去先发优势。

为了抢占先机，Sylvie 在漏洞保密期内提前考察了赏金项目，并检查这些厂商的网站是否易受 React2Shell 影响。这样一来，Meta 一公布漏洞，他们就能立刻去认领这些第三方的赏金。

问题是，在 React2Shell 公开之前，Vercel 已在其 Web 应用防火墙（WAF）中为该漏洞添加了过滤规则，即便客户站点仍在运行存在漏洞的 React 或 Next.js 版本，也能得到保护。Meta 和 Vercel 还与 Cloudflare 等 WAF 平台合作，教会它们如何过滤 React2Shell 攻击。

因此，Meta 公布 React2Shell 后，Sylvie 尝试在之前考察过的网站上复现漏洞，却未能触发。几乎所有设有赏金的网站都接入了 Cloudflare 或 Vercel，WAF 拦截了她的 exploit。

于是，Lachlan 和 Sylvie 必须想办法绕过 Cloudflare 和 Vercel 的 WAF 来触发 React2Shell，但绕过企业级 WAF 本身就是一个巨大的研究课题。好在 Sylvie 在 Cloudflare 的 WAF 中找到一个绕过方法，并在 Vercel 的 WAF 中找到了五个不同的绕过方法。

有意思的是，Sylvie 的大部分收入并非来自 React2Shell 本身，而是来自这些 WAF 绕过，因为 Vercel 对每个绕过支付 5 万美元。

收尾

完成了什么？

• 发布了新章节：“用 AI 提升写作”和“站在读者的角度”
• 与读者举办了一场关于用 AI 提升写作的线上交流
• 通过漏洞赏金项目报告了大量安全漏洞

经验教训

• 长远来看，专注于写书比追逐安全漏洞赏金对我更有利。
  • 难点在于，漏洞赏金的回报是即时的，而写书的回报往往要滞后至少一个月才会显现。
• 从云服务迁移到本地自托管的体验出乎意料地令人满足。

下月目标

• 让《Refactoring English》达到“内容完备”状态。
• 做一个工具，让《Refactoring English》的读者在阅读过程中可以直接提供反馈。

需要帮助

如果你有兴趣学习如何在团队代码中用 AI 发现安全漏洞，欢迎加入我的意向名单。如果感兴趣的人足够多，我就会着手开课。

• 意向登记——用 AI 发现安全漏洞