| ▲ | Claude Wrote a Full FreeBSD Remote Kernel RCE with Root Shell (CVE-2026-4747)(github.com) |
| 95 points by ishqdehlvi 8 hours ago | 30 comments |
| |
|
| ▲ | magicalhippo 3 hours ago | parent | next [-] |
| Key point is that Claude did not find the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug. That said, given how things are I wouldn't be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. If not now, then surely not in a too distant future. [1]: https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08... |
| |
| ▲ | Cloudef an hour ago | parent | next [-] | | You can let agent churn unattended if you have some sort of known goal. Write a test that should not pass and then tell the agent to come up with something that passes the test without changing the test itself. For this kind of fuzzing llms are not bad. | | |
| ▲ | vinnymac 7 minutes ago | parent [-] | | When doing this remove write permissions on the test file, it will do a much better job of staying the course over long periods. I've been doing this for over a year now. |
| |
| ▲ | ogig an hour ago | parent | prev | next [-] | | Setting up fuzzing used to be hard. I haven't tried yet, but my bet is having Claude Code, today, analyze a codebase and suggest where and how to fuzztest it and having it review the crashes and iterate, will produce CVEs. | |
| ▲ | fragmede 3 hours ago | parent | prev | next [-] | | > Credits: Nicholas Carlini using Claude, Anthropic Claude was used to find the bug in the first place though. That CVE write-up happened because of Claude, so while there are some very talented humans in the loop, Claude is quite involved with the whole process. | | |
| ▲ | magicalhippo 3 hours ago | parent | next [-] | | > Claude was used to find the bug in the first place though. That CVE write-up happened because of Claude Do you have a link to that? A rather important piece of context. Wasn't trying to downplay this submission the way, the main point still stands: But finding a bug and exploiting it are very different things. Exploit development requires understanding OS internals, crafting ROP chains, managing memory layouts, debugging crashes, and adapting when things go wrong. This has long been considered the frontier that only humans can cross. Each new AI capability is usually met with “AI can do Y, but only humans can do X.” Well, for X = exploit development, that line just moved. | | | |
| ▲ | bayindirh 2 hours ago | parent | prev [-] | | Yes, that claim needs a source. |
| |
| ▲ | petcat 3 hours ago | parent | prev [-] | | > have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. FreeBSD kernel is written in C right? AI bots will trivially find CVEs. | | |
| ▲ | pjmlp 3 hours ago | parent [-] | | The Morris worm lesson is yet to be taken seriously. | | |
| ▲ | pitched 2 hours ago | parent [-] | | We’re here right now looking at a CVE. That has to count as progress? |
|
|
|
|
| ▲ | ptx 3 hours ago | parent | prev | next [-] |
| > It's worth noting that FreeBSD made this easier than it would be on a modern Linux kernel: FreeBSD 14.x has no KASLR (kernel addresses are fixed and predictable) and no stack canaries for integer arrays (the overflowed buffer is int32_t[]). What about FreeBSD 15.x then? I didn't see anything in the release notes or the mitigations(7) man page about KASLR. Is it being worked on? NetBSD apparently has it: https://wiki.netbsd.org/security/kaslr/ |
| |
|
| ▲ | panstromek 3 hours ago | parent | prev | next [-] |
| The talk "Black-Hat LLMs" just came out a few days ago: https://www.youtube.com/watch?v=1sd26pWhfmg Looks like LLMs are getting good at finding and exploiting these. |
| |
|
| ▲ | dnw an hour ago | parent | prev | next [-] |
| Thanks for sharing the prompts: https://github.com/califio/publications/blob/main/MADBugs/CV... |
|
| ▲ | sheepscreek an hour ago | parent | prev | next [-] |
| I find it more concerning that this is still considered newsworthy. Frontier LLMs in the hands of anyone willing to learn and determined can be a blessing or curse. |
|
| ▲ | dheerajmp an hour ago | parent | prev | next [-] |
| You do not need Claude for finding FreeBSD vulns. Just plain eyes. Pick a file you can find one. |
|
| ▲ | m132 3 hours ago | parent | prev | next [-] |
| Appreciate the full prompt history |
| |
| ▲ | ptx 3 hours ago | parent | next [-] | | Well, it ends with "can you give me back all the prompts i entered in this session", so it may be partially the actual prompt history and partially hallucination. | |
| ▲ | dark-star 2 hours ago | parent | prev [-] | | they read like they were done by a 10 year old | | |
| ▲ | m132 2 hours ago | parent [-] | | They do, the whole tone and the lack of understanding of Docker, kernel threads, and everything else involved make it sound hilarious at first. But then you realize that this is all the human input that led to a working exploit in the end... | | |
| ▲ | bluGill an hour ago | parent [-] | | Freebsd doesn't have docker. It has jails which can serve a similar purpose but are not the same in important ways | | |
|
|
|
|
| ▲ | fragmede 3 hours ago | parent | prev | next [-] |
| https://github.com/califio/publications/tree/main/MADBugs/CV... would have been a better link |
|
| ▲ | PunchyHamster 3 hours ago | parent | prev | next [-] |
| I'm just gonna assume it was asked to fix some bug and it wrote exploit instead |
|
| ▲ | rithdmc 3 hours ago | parent | prev [-] |
| Running into a meeting, so won't be able to review this for a while, but exciting. I wonder how much it cost in tokens, and what the prompt/validator/iteration loop looked like. |
