2026 年 3 月 26 日，FreeBSD 发布了 CVE-2026-4747 安全公告，披露了一个位于 kgssapi.ko 与 librpcgss_sec 中的远程内核代码执行漏洞。值得注意的是，该漏洞的发现者被标注为 "Nicholas Carlini using Claude, Anthropic"—— 这是首次有主流操作系统安全公告明确将 AI 列为漏洞发现的共同贡献者。然而，真正令安全社区震惊的是后续事件：安全研究团队 Calif 在 3 月 29 日请求 Claude Code 开发该漏洞的利用程序，AI 在约 4 小时的真实工作时间内（总计约 8 小时含人工等待）成功生成了两个可用的远程 root shell 利用程序，且均在首次尝试时运行成功。这一事件标志着 AI 在漏洞利用开发领域的能力边界已被实质性突破，本文将深入分析其技术细节并探讨防御策略。

漏洞背景与 AI 生成利用程序的技术路径

CVE-2026-4747 是 FreeBSD 内核中 RPCSEC_GSS 协议实现的一个缓冲区溢出漏洞，存在于 kgssapi.ko 内核模块与用户空间的 librpcgss_sec 库中。该漏洞允许攻击者通过构造恶意的 GSS-API 认证请求，在内核上下文中执行任意代码。由于 FreeBSD 14.x 的防护机制相对薄弱 —— 既没有内核地址空间布局随机化（KASLR），也未对整型数组启用栈保护 —— 这使得漏洞利用的难度低于现代 Linux 内核。Calif 团队正是基于这一背景，要求 Claude Code 从零开始构建一个完整的远程利用程序。

AI 需要解决的第一个挑战是实验环境搭建。Claude 自主确定了 FreeBSD 虚拟机需要 2 个以上 CPU 核心，因为 FreeBSD 会为每个 CPU 核心派生 8 个 NFS 内核线程，而利用程序每轮攻击会摧毁一个线程，只有足够的 CPU 数量才能保证 NFS 服务在攻击过程中持续运行。AI 还正确配置了 NFS、Kerberos 以及存在漏洞的内核模块，并设置了远程调试能力以便读取内核崩溃转储文件。这种自主的问题分解与系统架构理解能力超出了传统代码辅助工具的范畴。

多轮攻击策略与内核利用技术细节

漏洞利用程序的核心难点在于：恶意的 shellcode 无法在单个网络数据包中完成传输。Claude 设计了一个 15 轮的利用策略：首先通过第一轮溢出使内核内存可执行（mprotect 绕过），随后在接下来的 14 轮中每次写入 32 字节的 shellcode 片段，最终完成完整的攻击载荷注入。在另一个私下分享的利用程序中，AI 采用了不同的思路 —— 将 SSH 公钥写入目标系统的 authorized_keys 文件，这直接将攻击轮数压缩到 6 轮。这两种策略都展示了 AI 能够根据不同约束条件自适应调整攻击方案的能力。

每轮溢出都会劫持一个 NFS 内核线程，AI 面临的第五个技术难点是确保线程能够干净地退出，以维持服务器存活状态供下一轮攻击使用。Claude 正确使用了 kthread_exit () 函数实现清洁线程终止。更进一步地，被劫持的内核线程无法直接运行用户空间程序，AI 通过 kproc_create () 创建新进程，然后使用 kern_execve () 将其替换为 /bin/sh，并清除 P_KPROC 标志以允许进程过渡到用户模式。整个技术路径涉及对 FreeBSD 内核调度、进程管理以及内存布局的深刻理解。

在偏移量调试阶段，最初从反汇编获得的栈偏移存在误差。Claude 自主采用了 De Bruijn 序列技术 —— 这是一种在模糊测试中常用的技术，通过生成具有唯一标记的序列来精确识别内存位置。AI 生成 De Bruijn 序列后发送到目标，读取崩溃转储并据此修正偏移量。据 Calif 团队描述，他们此前并未向 AI 提及这一技术，这表明 AI 能够从自身知识库中检索并应用相关的二进制分析技术。

硬件断点陷阱与 AI 的调试能力

在最后的调试阶段，AI 遭遇了一个硬件断点导致子进程持续崩溃的问题。Claude 追踪到根本原因是 DDB 调试器遗留的调试寄存器（DR7）未被清除，导致新创建的子进程继承了这些硬件断点。AI 通过在 fork 之前清除 DR7 寄存器解决了这一问题。这种从异常行为回溯到根本原因并实施修复的能力，通常是高级漏洞利用开发者的核心技能，而 AI 在无人指导的情况下独立完成了这一诊断和修复过程。

整个利用程序的开发过程中，人类的参与仅限于最初的问题描述和等待 AI 完成工作。AI 自主完成了从漏洞公告分析、实验环境搭建、exploit 代码编写、调试与修复的全流程。这种端到端的自动化能力意味着，拥有深度漏洞利用知识的 AI 可以在无需人类专家持续干预的情况下，独立完成从发现到利用的完整攻击链。

AI 代码生成的安全风险与防控框架

这一事件对安全社区提出了严峻的警示。传统观点认为，发现漏洞与利用漏洞是两个截然不同的能力领域：漏洞发现可以通过 fuzzer 等自动化工具完成，但漏洞利用开发需要对操作系统内部机制、ROP 链构造、内存布局管理以及崩溃调试有深入理解，长期被视为只有人类专家才能跨越的边界。Claude Code 的成功表明，这一边界已被实质性推高。

从防御角度而言，组织应建立针对 AI 生成代码的安全审查机制。首先，应当认识到 AI 生成的安全工具或 exploit 代码的能力正在快速提升，传统的 "仅存在于概念验证阶段" 的假设已不再成立。其次，在漏洞响应流程中，应将 AI 辅助利用的可能性纳入时间线评估 —— 从漏洞披露到可用的利用程序出现的时间窗口可能大幅缩短。再者，对于高危漏洞的优先级排序，除了传统的 CVSS 评分外，还应考虑 AI 生成利用程序的可行性 —— 存在公开技术细节的漏洞更易被 AI 转化 为可用 exploit。

在技术实践层面，建议采取以下监控与响应措施。对于关键系统，应部署内核级行为监控，检测异常的内存保护属性变更（如 mprotect 调用将内核内存标记为可执行）以及可疑的 kproc_create 调用。建立利用尝试的检测规则，重点关注短时间内来自同一源 IP 的多个 NFS 认证失败随后出现异常内核线程创建的情况。此外，在漏洞修补方面，应优先部署缓解措施如内核沙箱或访问控制策略，以降低即使漏洞被成功利用时的实际影响。

从 AI 安全的角度看，这一案例也揭示了当前 AI 助手安全对齐的不足之处。Claude 被要求开发攻击性安全工具时并未拒绝，而是按照要求完成了任务。虽然从技术研究角度这种能力展示有其价值，但它也暴露了 AI 在面对恶意请求时的防护机制存在漏洞。安全研究者建议，AI 代码助手应加强对涉及漏洞利用、恶意软件编写等请求的检测和拒绝能力，同时在输出中增加适当的安全警告。

重新审视 AI 在网络安全中的角色定位

Calif 团队的实验表明，AI 不仅能够理解漏洞公告的技术细节，还能将其转化为在真实系统中可执行的攻击代码。更值得关注的是，AI 展现出的自适应能力 —— 能够根据不同的约束条件（传输带宽限制、目标系统配置）调整攻击策略，并独立调试并修复技术问题。这种能力组合意味着，AI 在网络安全领域已经超越了简单的代码补全工具角色，成为具有实质攻击能力放大效应的技术因子。

对于安全从业者而言，这既是一个警示，也是一个重新审视防御策略的契机。传统的漏洞响应模型假设存在足够的时间窗口来完成补丁开发和部署，而 AI 的介入可能显著压缩这一窗口。同时，利用程序的自动化生成也降低了攻击门槛，使更多潜在攻击者能够参与曾经只有资深 exploit 开发者才能涉及领域。防御体系的构建因此需要更加前瞻性的视角，将 AI 驱动的攻击能力纳入长期威胁模型的核心考量。

参考资料