Anthropic 研究科学家 Nicholas Carlini 在 [un] prompted AI 安全会议上分享了一个里程碑式案例：他使用 Claude Code 在 Linux 内核中发现了多个可远程利用的安全漏洞，其中一个漏洞自 2003 年引入后隐藏长达 23 年未被发现。这一成果标志着 AI 辅助代码审计从概念验证进入工程化实用阶段。
自动化审计的工程化实现
Carlini 使用的自动化审计框架核心思路极为简洁：通过文件系统遍历配合大语言模型的上下文注入，实现对整个代码库的自动化漏洞扫描。其脚本逻辑可概括为三个关键步骤：遍历目标代码库的所有源文件、向模型注入特定上下文（CTF 场景）、收集模型发现的漏洞报告。为避免重复发现同一漏洞，脚本采用轮询策略 —— 每次仅向模型提示单个文件，引导其聚焦分析。
这种设计暴露了一个重要工程参数：上下文窗口的精准控制。模型需要足够的目标代码信息来进行推理，但过多的无关代码会稀释关键信号。Carlini 的实践表明，将分析范围限定在单个文件级别，配合指向性提示（hint 参数），能够有效触发模型的深度代码理解能力。
漏洞根因深度解析
被重点展示的 NFS 驱动漏洞是一个典型的堆缓冲区溢出（heap buffer overflow），其触发条件涉及 NFSv4 协议的状态管理机制。漏洞存在于 NFS 服务器响应锁冲突请求时的 Replay 缓存实现中。当第一个客户端（Client A）获取文件锁并声明一个 1024 字节的 owner ID 后，第二个客户端（Client B）尝试获取同一文件的锁时，服务器会生成拒绝响应。
问题的关键在于：服务器使用了一个大小仅为 112 字节（NFSD4_REPLAY_ISIZE）的静态缓冲区来构造拒绝响应，而响应消息包含了客户端提供的 owner 字段。在最坏情况下，消息总长度可达 1056 字节，导致内核堆内存被 attacker 可控数据覆盖。模型需要理解 NFSv4 协议的状态机、锁管理机制以及内存分配策略，才能识别这一跨函数的数据流问题。
这个漏洞的特殊性在于它并非明显的 API 误用或常见的模式化缺陷，而是协议状态机实现中的逻辑漏洞。Claude Code 不仅需要识别代码中的内存操作，还需要推理出两个不同客户端之间的交互如何导致边界检查失效。
缺陷模式与检测阈值
从漏洞特征可以提炼出以下可复用的检测参数：当代码中存在固定大小缓冲区（如 112 字节）且该缓冲区用于存储外部输入的可变长度字段时，应标记为高风险。对于 Replay 缓存类结构，建议将缓冲区大小设置为最大可能输入的两倍以上，以容纳协议扩展。
另一个关键阈值是历史代码的审查优先级。该漏洞自 2003 年引入后经历了漫长的代码演化周期，期间多次内核版本更新都未触及这一代码路径。这提示了一个实用原则：代码库中存在长期未修改的模块（特别是涉及网络协议实现的模块），其潜在风险往往被低估。
AI 模型能力梯度与实际应用
Carlini 的对比实验揭示了模型版本与漏洞检测能力的强相关性。使用 Claude Opus 4.6（发布不足两月）发现的漏洞数量显著高于 Opus 4.1（八个月前）和 Sonnet 4.5（六个月前）。这表明模型在代码推理能力上存在明显的代际跃升，且这一跃升在安全审计任务中体现得尤为突出。
对于工程团队而言，这意味着选择合适的模型版本直接决定了审计效果。建议在安全关键代码的审查中采用最新旗舰模型，而非依赖成本更低的上一代模型。同时，当发现新模型发布时，应对已有代码进行回顾性扫描 —— 正如本案例所示，新模型可能发现历史代码中从未被识别的缺陷。
工程实践参数清单
基于上述分析，可提取以下可直接落地的工程参数：扫描策略上，建议对涉及网络协议处理、内存分配、用户输入处理的代码模块优先扫描；模型调用策略上，单文件上下文注入优于全代码库一次性扫描，提示中的指向性信息（hint）能显著提升检出率；阈值设定上，涉及固定长度缓冲区且处理可变长度输入的代码应自动触发高危标记；审查优先级上，超过五年未修改的协议处理代码应纳入强制审查范围。
Carlini 在演讲中提到，他目前已发现数百个潜在漏洞，但验证瓶颈在于人工复核环节。这揭示了 AI 辅助审计的另一个重要趋势：自动化发现已相对成熟，而自动化验证（特别是排除误报）将成为下一阶段的核心挑战。
资料来源：Nicholas Carlini 在 [un] prompted 2026 会议上的演讲，详见 https://www.youtube.com/watch?v=1sd26pWhfmg