Claude Code挖出Linux内核隐藏23年的漏洞：一个bash脚本，5个零日，AI安全审计的时代来了

导语

Anthropic研究科学家Nicholas Carlini在[un]prompted AI安全大会上公布了一项震撼性成果：他用Claude Code和一个简单的bash脚本，在Linux内核中发现了5个可远程利用的安全漏洞——其中一个在NFS驱动中潜伏了整整23年，甚至比git本身还早。

更有意思的是发现过程：没有自定义工具，没有复杂提示词，只是让Claude Code逐个文件扫描，告诉它"你在参加CTF比赛"。

与此同时，Linux内核维护者的感受更加直观：内核安全邮件列表的报告量，已从每周2-3条上升到每天5-10条，而且"大多数都是正确的"。

AI辅助漏洞发现从"未来可能"变成了"正在发生"。

---

一、核心事件还原

1.1 关键信息速览

维度	信息
发现者	Nicholas Carlini，Anthropic研究科学家
使用工具	Claude Code（Claude Opus 4.6）
发现漏洞数	5个已确认的Linux内核漏洞
潜在发现	数百个崩溃点等待人工验证
最久远漏洞	NFS驱动堆缓冲区溢出，来自2003年的一次提交
漏洞覆盖	NFS、io_uring、futex、ksmbd
当前状态	已有对应内核补丁进入stable分支
论文/演讲	[un]prompted大会，YouTube可观看

1.2 发现方法：极简bash脚本

Carlini的方法出人意料地简单：

# 遍历Linux内核源码中的每个文件
find . -type f -print0 | while IFS= read -r -d '' file; do
  claude \
    --verbose \
    --dangerously-skip-permissions \
    --print "You are playing in a CTF. \
    Find a vulnerability. \
    hint: look at $file \
    Write the most serious one to the /output dir"
done

核心思路：

• 逐文件扫描：每次只让Claude Code看一个文件，避免上下文过载
• CTF场景设定：将安全审计包装成CTF比赛的上下文，激活模型的攻防思维
• 无需自定义工具：不依赖任何静态分析器或模糊测试工具

1.3 那个潜伏23年的NFS漏洞

这个漏洞的技术细节值得展开：

维度	说明
位置	Linux内核NFSv4驱动
类型	堆缓冲区溢出（Heap Buffer Overflow）
来源	2003年的一次代码提交（早于git）
攻击方式	两个协同NFS客户端针对一台服务器发起操作
攻击原理	客户端A申请1024字节的owner ID锁→客户端B请求同一把锁被拒→服务器生成1056字节拒绝响应→但响应缓冲区只有112字节→溢出写入，攻击者可控内核内存
可利用性	可远程利用，无需本地权限

简单说：服务器准备了112字节的碗，却倒进了1056字节的水。 这个错误从2003年存在至今，23年间无数人工代码审计都未能发现。

---

二、模型能力的爆发式跃迁

2.1 不同模型的发现能力对比

Carlini做了一个关键对比实验：

模型	发布时间	漏洞发现能力
Claude Opus 4.1	8个月前	只能发现Opus 4.6发现的一小部分
Claude Sonnet 4.5	6个月前	仍然只能发现一小部分
Claude Opus 4.6	当前	发现5个已确认漏洞+数百个待验证崩溃点

短短几个月内，漏洞发现能力出现了数量级的跃迁。 这意味着"AI辅助漏洞发现成为日常流程"的时间窗口正在快速逼近。

2.2 为什么Claude Code能做到

传统安全工具（静态分析、模糊测试）的局限：

工具类型	优势	局限
静态分析	能扫描大量代码	误报率极高，需要大量人工确认
模糊测试	能发现真实漏洞	缺乏上下文，崩溃难以定性
LLM Agent（Claude Code）	兼具上下文理解和验证能力	误报率低于20%，能自行验证

安全研究员Thomas Ptacek的评价精准概括了这一突破：

“LLM智能体漏洞发现是模糊测试和静态分析两者的超集。”

Claude Code会在代码库中递归生成假设、执行验证步骤、给出置信度，并通过明确的输入路径和攻击原语把发现放回具体上下文。这是传统工具完全不具备的能力。

2.3 行业侧的反馈

Linux内核维护者Greg Kroah-Hartman（Reddit）：

“大约一个月前发生了某些变化，整个世界都不一样了。现在我们收到的是真实报告……所有开源安全团队现在都在面对这个情况。”

另一位内核维护者Willy Tarreau（LWN）：

“内核安全列表的报告量已从每周2-3条上升到每天5-10条，而且现在其中大多数都是正确的。”

Redis创建者Salvatore Sanfilippo（Hacker News）：

“验证步骤正越来越多地由模型自身完成。如果第二条流水线无法复现崩溃，误报通常会在进入人工审查前就被剔除。”

实测误报率：根据使用Claude Opus 4.6做类似工作的经验，误报率低于20%。

---

三、"双重用途"的达摩克利斯之剑

3.1 攻防一体

正如Reddit评论者所指出的：

“如果AI能挖出Linux中潜伏23年、人工审计遗漏的漏洞，那么具备同等能力的对手也能把这套流程规模化用于目标攻击。”

这是一个经典的双刃剑问题：

用途	场景
防御	安全团队用AI审计自家代码，发现潜伏多年的漏洞
攻击	攻击者用AI扫描目标系统，批量发现可利用漏洞

同样的工具，同样的提示词，目标不同，结果天差地别。

3.2 对开发者的实际影响

1. 安全审计门槛大幅降低：不再需要顶尖安全专家，Claude Code就能完成初步审计
2. 遗留代码风险暴露：像那个23年的NFS漏洞一样，很多老代码中可能潜伏着类似问题
3. 补丁压力增大：AI发现的漏洞数量远超人工时代，安全团队可能面临"补不过来"的局面
4. 安全开发生命周期需要升级：将AI审计纳入CI/CD流程，将成为新的安全实践标准

---

四、AI辅助安全审计的实践建议

4.1 推荐工作流

对于希望利用AI进行代码安全审计的开发团队：

1. AI初步扫描（Claude Code / GPT / DeepSeek）
   ↓
2. AI自行验证（交叉确认，过滤误报）
   ↓
3. 人工复核（安全专家审查高置信度发现）
   ↓
4. 修复+回归测试

4.2 模型选择建议

在安全审计场景中，模型选择至关重要：

• Claude Code（Opus 4.6）：当前已知最强的代码安全审计模型，实测误报率低于20%
• GPT系列：代码理解能力强，但在安全场景的针对性可能不如Claude
• DeepSeek：性价比高，适合大规模初步扫描
• 建议策略：多模型交叉验证，降低单一模型的盲区风险

4.3 多模型接入的价值

安全审计场景下，多模型接入的优势更加明显：

• 交叉验证：不同模型对同一代码的安全判断可能不同，互补性极强
• 成本优化：用便宜模型做初筛，用强模型做深度分析
• 能力覆盖：不同模型对不同类型漏洞的敏感度不同

推荐方案：通过A8 AI聚合中转统一接入多模型

A8 AI（napiai.com）的优势：

• 600+模型一键切换：Claude、GPT、DeepSeek、Qwen等全覆盖
• 智能路由：根据任务类型自动匹配最优模型
• 国内加速：无需翻墙直连海外模型，适合国内安全团队
• 统一计费：一套API Key管理所有模型调用

---

五、总结

Claude Code发现Linux内核23年隐藏漏洞这件事，标志着AI辅助安全审计正式从"实验"进入"实用"阶段。

几个关键判断：

1. 能力跃迁速度快于预期：8个月内从"只能发现一小部分"到"发现23年零日"，模型进化速度惊人
2. "AI辅助漏洞发现"即将成为安全团队标配：Linux内核维护者已经在面对每天5-10条有效报告的新常态
3. 双重用途风险不可忽视：攻防双方都将获得AI加持，安全竞赛进入新阶段
4. 多模型交叉审计将成为最佳实践：单一模型有盲区，多模型互补才能最大程度降低风险

对开发者而言，现在最该做的不是观望，而是马上在自己的项目中尝试用AI做一次安全审计——你可能会惊讶于它能发现什么。

---

核心关键词： Claude Code, Linux内核漏洞, AI安全审计, 零日漏洞, NFS堆缓冲区溢出, Anthropic, Nicholas Carlini, 模糊测试, 静态分析, AI编程, API聚合, A8 AI, 多模型接入, Claude Opus 4.6, 代码安全