Claude 写出远程 root shell 后，AI 编码最危险的阶段开始了

大多数人提到 AI 写代码，想到的还是搭页面、补 CRUD、写脚本。

但这两天开发者社区讨论的一件事，已经把这条能力边界往前推了一大截：Claude 被公开用于完成一条 FreeBSD 远程内核 RCE，并最终打到 root shell。

真正值得警惕的，不是“AI 又秀了一把”，而是它开始碰到最危险的那层系统边界。

这不是“AI 自主黑客觉醒”

这次讨论对应的是公开 write-up 里的 CVE-2026-4747。目标环境是 FreeBSD 的 NFS server，在启用 kgssapi.ko、走 RPCSEC_GSS 路径时，内核函数 svc_rpc_gss_validate() 会把 RPC 头重建进一个 128 字节的栈缓冲区。前面固定头部先占了 32 字节，后面却还会按 oa_length 把 credential body 整段 memcpy 进去，但没有检查是否超过剩余空间。

结果就是：credential body 足够大时，栈会被冲穿，覆盖局部变量和返回链路，最后碰到返回地址。补丁本身其实很朴素，本质上就是把边界检查补上。

从技术根因看，这仍然是一个经典漏洞：不是“黑魔法”，就是一个普通但致命的边界检查缺失。

真正不普通的是它指向的结果：这不是普通用户态崩溃，也不是一个 Web 服务 RCE，而是 FreeBSD 内核路径里的远程代码执行，最后能拿到 root shell。

真正让人不安的，是能力边界变了

过去一年，很多人对 AI 编码的想象还停在三个场景：写页面、写业务逻辑、补测试修 bug。哪怕再往前一步，也不过是“帮忙写个 exploit demo”的辅助工具。

这次不一样。

它碰到的是内核代码路径、远程攻击面、真实系统约束，以及最终的 root shell。公开 write-up 里写到的不只是“AI 找到了 bug”，还包括栈布局、偏移、返回地址落点、VM 配置、KDC 环境、CPU 数量对成功率的影响。这已经很接近完整的 exploit engineering，而不是实验室里的玩具 PoC。

<figure><img src=“images/compare.png” /><figcaption>从普通 AI 编码想象，到进入内核漏洞利用研发，危险等级已经不是一个层面。</figcaption></figure>

为什么这条 FreeBSD exploit 特别能说明问题

第一，它不是“随便打个包过去就炸”的低门槛漏洞。攻击方需要走 RPCSEC_GSS，服务端还得已经存在有效 client entry，重放检查也要通过。这意味着研究者必须真正理解协议、上下文和目标系统。

第二，它不是“理论可行”就收工。公开 write-up 交代了 exploit 从理解、试错到收敛的完整过程。这里最重要的信号，不是 Claude 有多聪明，而是它已经能在高门槛安全研究里承担一大块原本很费体力的工作。

第三，它最后给出的不是抽象威胁，而是所有技术人一眼就明白的结果：root shell。到这里，讨论焦点已经不该是“AI 会不会做研究”，而是“AI 已经能把一类高风险研究推进到什么深度”。

真正该紧张的，是门槛在下移

我并不觉得这意味着“以后人人都能让 AI 写内核 0day”。高质量 exploit 研发依旧需要人来选目标、读上下文、判断哪条路径值得深挖，还要在系统限制里反复试错。

但危险恰恰在这里。

AI 不需要把人完全替代掉，只要把原来 10 个人里 1 个人能做的事，慢慢变成 10 个人里 3 个人能做，局面就已经变了。对攻击侧来说，这意味着前期最贵、最枯燥、最容易卡死的探索成本正在下降。以后更现实的图景，不是“AI 独立攻击互联网”，而是一个原本水平中等的攻击者，带着 AI，能以更接近高级研究员的速度往前推进。

这会直接改变攻防节奏。

对普通开发团队来说，这个信号比很多 AI 发布会都重要

很多公司现在谈 AI 编码，关注点还停在提效和提速。这当然没错，但如果你只把它理解成“帮工程团队省时间”，就会漏掉另一半变化。

同样的提效逻辑，也会发生在安全研究和攻击开发这边。你今天少写 30% 模板代码，对手明天也可能少花 30% 时间把某条脆弱路径跑通。你让 AI 帮你补单测，对方也可能在用它读协议、拆结构体、整理 crash 线索、生成试验脚本。

所以这件事给团队最现实的提醒，不是“别用 AI”，而是三件更硬的事：默认安全配置要更保守，补丁速度要更快，防守侧也必须把 AI 真正接进审计、diff 分析、暴露面梳理和配置检查这些工作流里。

<figure><img src=“images/workflow.png” /><figcaption>进攻侧被 AI 放大以后，防守侧也必须把 AI 接进真正的安全工作流，而不只是拿来聊天和写周报。</figcaption></figure>

最后

Claude 写出这条 FreeBSD 远程内核 RCE，当然很震撼。

但真正麻烦的，不是“它居然能写 exploit”，而是我们大概已经走到一个新阶段：AI 编码的竞争，不再只是“谁把产品做得更顺手”，也开始变成“谁先把危险能力规模化”。

这次是 FreeBSD，下次未必还是内核。可方向已经很清楚了。

以后谈 AI 安全，重点可能不该只盯着幻觉和胡说八道，更该盯住它正在把哪些原本昂贵、稀缺、危险的能力，变成更便宜的常规能力。

如果 exploit 开发的门槛继续往下掉，你觉得谁会先顶不住？

数据来源：califio/publications 中的 CVE-2026-4747 公开 write-up、Hacker News 讨论串。