AI 开始帮黑产找漏洞了，产品团队还来得及补吗？

很多团队以前默认一件事：漏洞就算存在，从被发现到被真正利用，中间通常还有一段缓冲期。

但这段缓冲期，正在被 AI 压短。

最近 Claude Code 帮研究员从 Linux 内核里翻出一个潜伏 23 年的 NFS 漏洞。这件事真正可怕的，不只是 AI 已经能啃老代码、老协议、老状态机了。

更可怕的是，一旦漏洞发现这件事变便宜，最先被放大的不只会是白帽能力，也会是黑产能力。

过去很多历史漏洞之所以能在系统里躺很多年，不一定是因为它完全没人知道，而是因为把它从老代码里真正翻出来、确认成可利用问题，本来就很费人、很费时间、也很费耐心。

现在这个门槛在往下掉。

以前只有少数高手愿意慢慢啃的旧模块、边缘接口、历史兼容逻辑，以后都可能被 AI 批量筛一遍。对黑产来说，这意味着什么很直接：扫目标更快，找变体更快，补利用链也会更快。

所以这件事不该只被理解成“安全研究员效率提升了”。

它更像是在提醒所有做产品、做后端、做基础设施的人：

以后真正危险的，不是系统里有没有洞，而是你修洞的速度，能不能跑在黑产利用之前。

为什么老系统会先难受

因为老系统最适合被 AI 重新翻账。

这类地方通常有三个特点：

第一，代码老，补丁叠补丁，很多逻辑“能跑就别动”。

第二，理解成本高，要同时看历史兼容、输入路径、状态转换和边界条件。

第三，影响面大，一旦真出问题，往往不是一个小故障，而是一整条链路跟着抖。

以前人不愿意花大成本把这些地方重新读一遍，现在模型愿意，而且便宜得多。

这就是为什么一个 23 年的 Linux 漏洞会让人不安。它说明那些“大家以为不会有人再认真读”的地方，接下来很可能重新成为热点攻击面。

01-compare

以后先爆掉的，不一定是漏洞数量，而是修补节奏

很多团队现在的安全节奏，还是旧时代的节奏：

• 漏洞来了，先排队
• 评估一下影响
• 找时间修
• 挤窗口上线

这套流程以前还能转，是因为漏洞发现速度和漏洞利用速度之间，通常还有一点时间差。

但如果 AI 同时在帮研究员和黑产提速，这个时间差就会越来越短。

那产品团队最先感受到的，不是“漏洞突然多了十倍”，而是另外三种更现实的压力：

第一，历史包袱会被集中翻出来。 过去长期没事，不代表以后没事。

第二，验证和修补会变成真正的瓶颈。 发现问题不再最贵，来不及确认、来不及上线、来不及止血，才最贵。

第三，很多原本排在后面的安全债，会突然变成眼前债。 你以为还能拖到下个版本，黑产未必会给你这个时间。

02-workflow

产品团队现在该先做什么

如果你现在还把这件事理解成“安全团队自己会处理”，那就太晚了。

更实际的做法是先补三件事：

第一，把老模块、老接口、老兼容逻辑重新盘一遍。 尤其是那些“没人想碰”“改了怕炸”的区域，最值得先查。

第二，把修补链路提速。 不是等漏洞来了再临时拉群，而是提前把分级、验证、上线、回滚这些动作跑顺。以后慢的代价会越来越高。

第三，别再把安全债当成可无限顺延的技术债。 AI 会让很多旧问题更容易被看见，也更容易被利用。拖着不修，不再只是代码洁癖问题，而是时间窗口问题。

最后

Claude Code 找出一个潜伏 23 年的 Linux 漏洞，它真正值得所有技术团队警惕的，不是“AI 又强了一点”。

而是从这一刻开始，漏洞发现门槛正在下降，黑产的搜索能力也会一起变强。

接下来决定很多产品安不安全的，未必是谁先发现问题，而是谁能更快把问题修完。