夜雨聆风一个 112 字节的缓冲区。
一个 1024 字节的字段。
23 年没人发现。
Claude Code 花了几个小时。
这不是段子，这是真实发生的事。
先说一个故事：那个漏了 23 年的洞
今年 3 月，Anthropic 研究员 Nicholas Carlini 在 [un]prompted AI 安全大会上，讲了一件让整个安全圈后背发凉的事。
他让 Claude Code 扫描 Linux 内核源代码找漏洞。方法简单到令人震惊：一个 bash 脚本，遍历每个源文件，告诉 Claude "你现在在参加 CTF 比赛，找出漏洞"。没有自定义工具，没有复杂提示词，没有手把手指引。
就是用这么粗糙的办法，Claude 找到了好几个可以远程利用的堆缓冲区溢出漏洞。
其中一个，藏在 Linux 的 NFS（网络文件系统）驱动里。这个漏洞能让你从网络另一端，读到内核内存里的敏感数据。
它是什么时候被写进去的？
2003 年 3 月。比 Git 诞生早了整整两年。
23 年里，成千上万的安全研究员、静态分析工具、模糊测试工具，一遍遍扫过这段代码。没有一个发现它。
Claude 只用了几个小时。
怎么做到的？这个攻击逻辑有点绕，但理解了它，你就理解了为什么这比"AI 会写代码"严重得多。
攻击者需要两个 NFS 客户端配合。
首先，客户端 A 向 NFS 服务器申请一个文件锁，并在 owner ID 字段里塞了 1024 个字节——这是协议允许的合法长度，只是很少有人会用这么长的 ID。服务器检查没问题，批准了锁。
然后，客户端 B 登场。它也试图申请同一个文件的锁。服务器说"不行，已经有人锁了"，然后准备生成一条拒绝响应。
问题出在这里。
服务器生成拒绝响应时，包含了客户端 A 当初传入的那个 1024 字节的 owner ID。加上其他协议字段，整条响应消息总长 1056 字节。但是内核为这条响应准备的内存缓冲区，只有 112 字节。
1056 字节塞进 112 字节的空间里。
多出来的 944 字节，由攻击者控制，覆盖到了内核内存的其他区域。
这不是一个"可能被利用"的理论漏洞。这是攻击者可以精确控制被覆盖内容的、可远程触发的堆缓冲区溢出。
翻译一下：想想你家的信箱只能放下一本杂志，但有人硬塞了一套百科全书进去。信箱撑破了，书页散进了你家客厅。攻击者提前在这些"多余的书页"上写好了想放的东西。
这个漏洞如此典型地被忽略，恰恰暴露了人类代码审计的盲区。它不在常见的危险函数调用里，不在明显的内存操作错误里。它藏在协议语义的细节中——你得同时理解"NFS 协议的合法边界"和"内核实现的真实边界"，才能看出来。
传统的自动化工具就更没戏了。模糊测试随机扔数据，测试的是"输入会不会让程序崩溃"——但这个漏洞的关键不在输入，在协议状态转换。静态分析工具检查已知的危险模式——但这里没有危险模式，只有"两个看起来都合法的事情组合起来才非法"。
这就是为什么它藏了 23 年。每一代工具都照顾不到它。
Claude 看出来了。
为什么这次不一样
你可能会想：AI 发现的漏洞还少吗？GitHub Copilot 不早就在帮你找 bug 了？
让我解释一下这次的本质区别。
之前 AI 帮你做的事，是"帮你写"。你描述需求，它生成代码。它本质上是个效率工具——写得比你自己敲快一点，但写出来的东西你还是得自己检查。
这次不同。这次 AI 帮你做的事，是"帮你发现"——发现你没发现的东西，发现所有人都没发现的东西，发现被全世界最好的安全专家盯了 23 年都没发现的东西。
角色变了。从效率工具升级为认知放大器。
用一个比喻来说：之前 AI 像一个实习生，你说"帮我搭个页面"，它给你生成代码，然后你自己还得检查哪里不对。现在 AI 像一个高级安全顾问，你说"看看这段代码有没有问题"，它回来告诉你"第 347 行有个缓冲区溢出，能远程利用，攻击路径是这样的——"
角色翻转了。以前是你在审查 AI 的输出。现在是 AI 在审查你的输入。
这种升级有多猛？Carlini 本人就是最好的参照系。他是加州大学伯克利分校的博士，在 IEEE S&P 和 USENIX Security 上拿过最佳论文奖，在 Google Brain 和 DeepMind 都工作过。一个人职业生涯能拿到的顶级安全奖项，他差不多都拿了。
就是这样一个人，在大会上亲口说："我这辈子从来没找到过远程可利用的堆缓冲区溢出漏洞。这太难太难太难了。但有了这些大模型，我现在手上一堆。"
一个顶级安全专家二十几年没做到的事，AI 帮他做到了。而且不止一次，是一堆。
更扎心的是模型能力的跃迁速度。Carlini 用完全同样的方法测试了老版本模型：8 个月前发布的 Claude Opus 4.1，6 个月前发布的 Sonnet 4.5——它们只能找到 Claude Opus 4.6 的一小部分漏洞。
翻译一下这个变化：6 个月前还看不懂的事，现在已经能做几百次了。
这不是"快了一点"，这是"能干"和"干不了"的区别。
数字背后：AI 漏洞发现的真实面貌
如果你觉得这只是 Claude 一家在秀肌肉，那来摆一组数据。
Anthropic 团队用同样的流水线扫描了多个主流开源项目，总计发现了超过 500 个此前未知的高危漏洞。涵盖 Linux 内核、FreeBSD、glibc、Chromium、Firefox、WebKit、Apache HTTPd、GnuTLS、OpenVPN、Samba，甚至 NASA 的 CryptoLib。
500 个。这不是某个小作坊发现的，是 Anthropic 的红队在一个研究周期内的产出。
在 Linux 内核上，Carlini 已经确认了至少 5 个漏洞，分布在 NFS、io_uring、futex、ksmbd 等核心子系统里。他手上还有几百个崩溃报告没来得及验证——不是 AI 找不到了，是人不够用了。
这是场景完全反过来了：以前是成千上万的研究员围着代码找漏洞。现在是一个 AI 找到几百个漏洞，需要成千上万的人来验证。
Linux 内核的维护者感受最直接。
内核安全邮件列表的漏洞报告量，从之前的每周 2 到 3 条，飙升到了每天 5 到 10 条。而且和以往的"AI 垃圾报告"完全不同——这些报告大多数是正确的。
Linux 内核的首席维护者 Greg Kroah-Hartman 公开说了这样一句话："大约一个月前，某件事发生了。整个世界都不一样了。现在我们收到了真正的报告。"
几个月前，开发者还在嘲笑 AI 安全报告是"AI slop"（AI 垃圾）。几个月后，世界上最挑剔的代码库维护者已经改口了。
误报率？低于 20%。
这个数字是什么意思？每收到 5 份 AI 安全报告，4 份是真的。这已经接近人类安全研究员的水平了。很多时候甚至更高——毕竟人类也会累，会漏，会有盲区。
安全圈另一位重量级人物 Thomas Ptacek 给出了一个精准的判断："LLM Agent 的漏洞发现能力，是模糊测试和静态分析两者的超集。"
超集。不是替代，是包含。模糊测试能发现崩溃，但看不懂为什么崩溃、能不能利用。静态分析能发现模式问题，但理解不了跨文件的数据流和协议语义。LLM Agent 两样都能做，还能读懂提交历史找出"上次修了这个，这个类似的地方也修了没有"。
举个真实的例子：Claude 在 FreeBSD 上发现了一个栈缓冲区溢出漏洞（CVE-2026-4747），4 个小时内不仅找到了漏洞，还写了两个可用的远程 root 漏洞利用程序，两个都是一次成功。Carlini 只是离开键盘——Claude 自己完成了从发现到武器化的全过程。FreeBSD 的官方安全公告直接写了致谢："Nicholas Carlini using Claude, Anthropic."
你说这算什么？把工具名写进致谢名单，这在安全圈的历史上可能还是头一回。
但等一下——别急着欢呼
这篇文章不是来吹 AI 的。相反，越震撼的能力，越值得冷静地问一句：代价是什么。
第一：双重用途。
如果 AI 能挖出潜伏 23 年的漏洞，对手也能规模化地用于攻击。
这不是危言耸听。IBM X-Force 已经报告了 44% 的攻击增长，明确归因于"AI 驱动的漏洞发现"。而当同一个工具防御者能用、攻击者也能用时，问题是：谁动手更快？
攻击者找到漏洞→武器化→开始打→受害者可能都不知道有这个漏洞。
防御者找到漏洞→报告→等维护者修复→等下游更新→等用户打补丁。
这两个链条的时间差，从来没有像现在这样大。
Anthropic 坦率承认了这个问题：目前 Claude 找到漏洞的能力显著强于武器化漏洞的能力。但这只是一段窗口期，不是永久的护城河。
第二：验证危机。
Carlini 现在手上有几百个 AI 发现的潜在漏洞，但他一个人验证不过来。他不想把未经确认的"AI 垃圾"丢给内核维护者。
但换一个角度想：如果连 Anthropic 研究员都面对这个瓶颈，普通的安全团队怎么办？
工具给你找到了 200 个"疑似漏洞"的标记。你真的有足够的人手逐一验证吗？如果验证不过来，你是赌"大部分是误报"直接跳过，还是扩大安全团队？前者是风险，后者是成本。
这引出了另一个更深的顾虑：当误报率 20% 时，100 个报告里有 20 个假的。验证成本已经很高了。如果有一天误报率降到 5% 但报告量翻了 10 倍呢？你可能需要处理 950 个真漏洞。
这不是假设。在 [un]prompted 大会上，安全专家们已经成立了一个叫"Zero Day Clock"的联盟，核心论点就是：漏洞管理需要"根本性的重新思考"，因为从发现到利用的时间窗口正在以 AI 的速度坍塌。
你的团队准备好了吗？
第三：披露机制崩了。
安全研究这行有个惯例叫"90 天披露窗口"——发现漏洞后给厂商 90 天修，到时间不管你修没修好都公开。这个机制假设的是：漏洞是以人类的速度被发现的，每年几十个、上百个，维持者和安全团队还跟得上。
但现在是 AI 的速度了。Claude 在 Firefox 上两周找到了 22 个漏洞，其中第一个只用了 20 分钟。FresBSD 上的一个远程 root 漏洞，从 Claude 开始扫描到写出完整可用的漏洞利用代码，Carlini 只是离开键盘 4 个小时。
如果这种速度普及开来，90 天窗口根本不够用。一个月可能就有几百个漏洞涌入维护者的收件箱。
到那时候，整个安全行业的节奏都需要重新设计。
翻译一下：这对你意味着什么
咱们别光聊趋势。针对不同角色，这里是我的判断和建议。
### 如果你是开发者
AI 发现漏洞的能力已经接近甚至超过了大部分安全研究员。这意味着你不能再靠"我的代码肯定没人仔细看"来获取安全感了。
你应该做的事：把 AI 工具集成进 CI/CD 流水线。不是等出了事再查，而是每次提交代码就让 AI 扫一遍。Claude Code Security 已经向企业和团队客户开放了，开源维护者可以申请快速通道。
但别把 AI 扫一遍就当圣旨。把输出当线索，不当判决。20% 的误报率意味着每 5 条警报里有 1 条是假的——你依然需要人的判断。
### 如果你是安全研究员
这道题有点残酷。如果你做的是"我可以手工审计 1000 行代码发现一个 bug"这种事，AI 正在吃掉你的差异化优势。
但你的价值没有消失，只是变了位置。AI 擅长"找到可能有问题的地方"，但验证、分析影响范围、设计修复方案、判断是否被实际利用过——这些仍然需要人的判断和经验。
把 AI 当成你的初级搭档。让它扫代码，你来定优先级。你不再是挖坑的人，而是筛选金子的人。
一个具体建议：学会写能驱动 AI 做安全审计的脚本和提示词。这不比学会用 Burp Suite 更难，但回报可能更大。
### 如果你是团队决策者
这个变化不只是技术问题，是资源分配问题。
你需要做三件事：
第一，评估团队当前的漏洞管理流程能不能扛住 10 倍的报告量。如果不能，现在就该开始规划。
第二，把 AI 安全审计加入预算。不是"明年看看"，是今年就应该有。先选一个小而痛的场景——比如你最核心的那个服务，代码量不大但安全要求极高——跑一个月试试效果。
第三，关注补丁策略。修补速度会变成安全能力的核心指标。一个 23 年没被发现的老漏洞说明了一件事：暴露在外的代码，总有一天会被找到。问题是，找到它的人是你还是攻击者。
这就是我们现在面临的真实局面。
AI 不是来帮我们写代码更快的。它已经跨过了那条更重要的线：能发现我们几十年都没看到的东西。
那个 112 字节的缓冲区，那个 1024 字节的 owner ID，那个 Bugzilla 上找不到的 2003 年的提交——它们一起构成了一个清晰的信号。
信号是：代码安全的天平，正在从"隐蔽就是安全"转向"暴露是不可避免的"。
你选择坐在哪一边？
👉 如果你是开发者或安全研究员，分享一下你的应对方案
👉 如果觉得有收获，点赞/在看/转发 三选一
「风清扬」专注 AI Agent 与自动化工作流的深度观察。关注我，不错过每一篇分析。
