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.
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.
mentalgear 2 minutes ago [-]
it' s called brute force .
cryptbe 18 minutes ago [-]
>Key point is that Claude did not find the bug it exploits.
It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".
Cloudef 5 hours ago [-]
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 3 hours ago [-]
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.
fragmede 7 hours ago [-]
> 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 6 hours ago [-]
> 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.
jsnell 5 hours ago [-]
> Do you have a link to that? A rather important piece of context.
It was a quote from your own link from the initial post?
> Credits: Nicholas Carlini using Claude, Anthropic
magicalhippo 4 hours ago [-]
Oh wow, blind as a bat.
Would have been interesting with a write-up of that, to see just what Claude was used for.
jsnell 3 hours ago [-]
Obviously no guarantees that it's exactly what was done in this case, but he talked about his general process recently at a conference and more in depth in a podcast:
Claude is already able to find CVEs on expert level.
shimman 2 hours ago [-]
A talk given by an employee that stands to make millions from Anthropic going public, definitely not a conflict of interest by the individual.
pama 2 hours ago [-]
It is by the individual who (also with Claude) found the specific vulnerability used in this exploit.
muskstinks 2 hours ago [-]
I didn't say "watch this without critical thinking".
The chance this is completly fabricated though is very low and its an highly interesting signal to many others.
There was also a really good AI CTF Talk at 39c3 hacker conference just 4 month ago.
ale 1 hours ago [-]
But you did say “Claude is already able to find CVEs on expert level.”
muskstinks 1 hours ago [-]
Please also read my comments with critical thinking and add my comment and its content to your own list of signals you trust :P
2 hours ago [-]
Bender 2 hours ago [-]
Claude is already able to find CVEs on expert level.
Does it fix them as fast as it finds them? Bonus if it adds snarky code comments
snovv_crash 32 minutes ago [-]
I'm more interested if it fixes CVEs faster than it introduces them.
petcat 6 hours ago [-]
> 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 6 hours ago [-]
The Morris worm lesson is yet to be taken seriously.
pitched 6 hours ago [-]
We’re here right now looking at a CVE. That has to count as progress?
stephc_int13 1 hours ago [-]
The most difficult part is always to find the vulnerability, not to fix it. And most people who are spending their days finding them are heavily incentivized to not disclose.
Automatic discovery can be a huge benefit, even if the transition period is scary.
spookie 57 minutes ago [-]
Hopefully such automation also covers fixing instead of giving open source devs headaches, like the one over some obscure codec from the 90's.
Nevertheless, attacking is a targeted endeavour, unlike defense. Fixing is, in _general_, more difficult in theory.
* reference to past google and ffmpeg incident
panstromek 7 hours ago [-]
The talk "Black-Hat LLMs" just came out a few days ago:
Looks like LLMs are getting good at finding and exploiting these.
baq 6 hours ago [-]
Everybody is acts so surprised as if nobody (around here of all places!) read the sama tweet in which he was hiring the Head of Preparedness... in December.
Besides that i'm not reading x, what has this arbitary random tweet todo with antrophic, the yt talk about Opus quality Jump to find exploits no one else was able to find so far?
A theoretical random tweet and a clear demonstration are two different things.
eru 5 hours ago [-]
I never read any Twitter.
baq 5 hours ago [-]
X was the primary source, it's been since reported all over the news.
ptx 6 hours ago [-]
> 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?
This knob isn't KASLR, it just enables ASLR for ELF binaries.
keysersoze33 5 hours ago [-]
This is more of a Linux kernel criticism of KASLR, but perhaps it's related as to why it's not been a priority in FreeBSD (i.e. it gives a false sense of safety and rather focus on 'proper' security hardening): https://forums.freebsd.org/threads/truth-about-linux-4-6-sec...
pixl97 1 hours ago [-]
Security is an onion, honestly you want both layers to be as hard as possible.
the prompts show how this was a back-and-forth with a lot of nudging, interruptions and steering: it's not Claude writing a full exploit just from a vulnerability description.
neonstatic 1 hours ago [-]
> "Claude wrote"
I am hoping that quite soon we will have general acceptance of the fact that "Claude can write code" and we will switch focus to how good / not good that code is.
andrewstuart 22 minutes ago [-]
Errrr the headline makes it sound like a bad thing.
This is what Claude is meant to be able to do.
Preventing it doing so is just security theater.
m132 7 hours ago [-]
Appreciate the full prompt history
ptx 6 hours ago [-]
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.
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 5 hours ago [-]
Freebsd doesn't have docker. It has jails which can serve a similar purpose but are not the same in important ways
m132 5 hours ago [-]
Please at least read the context before attempting to correct me...
God damn, how much time am I wasting by writing full paragraphs to the Skinner box when I could just write half-formed sentences with no punctuation or grammar?
thwarted 2 hours ago [-]
> can we demon strait somehow a unpriv non root user
"demon strait". Was this speech to text? That might explain the punctuation and grammar.
johnisgood 2 hours ago [-]
Now give an excuse for pushing so hard for docker on FreeBSD.
Daishiman 2 hours ago [-]
It's amazing what an intelligence that has infinite patience can do to understand barely comprehensible gibberish.
bluGill 2 hours ago [-]
I'm not correcting you, I'm adding context for people who don't know much about freebsd.
addandsubtract 5 hours ago [-]
Welcome to vibe coding. If you ever lurk around the various AI subreddits, you'll soon realize just how bad the average prompts and communication skills of most users are. Ironically, models are now being trained on these 5th-grade-level prompts and improving their success with them.
_alternator_ 2 hours ago [-]
Just think about how your parents used google when you were a kid. What got better results faster?
sheepscreek 5 hours ago [-]
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.
But I found the exploit writeup pretty interesting
EGreg 2 hours ago [-]
This requires an SSH to be available?
Is it possible to pwn without SSH listening?
fragmede 53 minutes ago [-]
*NFS
jeremie_strand 6 minutes ago [-]
[dead]
imta71770 2 hours ago [-]
[dead]
jeremie_strand 4 hours ago [-]
[dead]
Adam_cipher 5 hours ago [-]
[dead]
bustah 4 hours ago [-]
[dead]
MYEUHD 4 hours ago [-]
This is an AI-generated comment.
volume_tech 3 hours ago [-]
[dead]
alcor-z 4 hours ago [-]
The MADBugs work is solid, but what's sticking with me is the autonomy angle — not just finding a vuln but chaining multiple bugs into a working remote exploit without a human in the loop. FreeBSD kernel security research has always been thinner on the ground than Linux, which makes this feel both more impressive and harder to put in context. What's the actual blast radius here — is this realistically exploitable on anything with default configs, or does it need very specific conditions?
Fnoord 3 hours ago [-]
FTA, top:
> Attack surface: NFS server with kgssapi.ko loaded (port 2049/TCP)
Not sure who would run an internet exposed NFS server. Shodan would know.
sitkack 39 minutes ago [-]
You also need a valid Kerberos ticket to get to the point where you can exploit.
dheerajmp 4 hours ago [-]
You do not need Claude for finding FreeBSD vulns. Just plain eyes. Pick a file you can find one.
htx80nerd 2 hours ago [-]
Another Claude glazing spam post. Can I get paid to post these? What is the URL to sign up for the Claude Glazing affiliate program?
PunchyHamster 7 hours ago [-]
I'm just gonna assume it was asked to fix some bug and it wrote exploit instead
xorgun 5 hours ago [-]
[dead]
rithdmc 7 hours ago [-]
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.
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...
It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".
For this kind of fuzzing llms are not bad.
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.
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.
It was a quote from your own link from the initial post?
https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08...
> Credits: Nicholas Carlini using Claude, Anthropic
Would have been interesting with a write-up of that, to see just what Claude was used for.
https://www.youtube.com/watch?v=1sd26pWhfmg
https://securitycryptographywhatever.com/2026/03/25/ai-bug-f...
It pretty much is just "Claude find me an exploitable 0-day" in a loop.
https://www.youtube.com/watch?v=1sd26pWhfmg
Claude is already able to find CVEs on expert level.
The chance this is completly fabricated though is very low and its an highly interesting signal to many others.
There was also a really good AI CTF Talk at 39c3 hacker conference just 4 month ago.
Does it fix them as fast as it finds them? Bonus if it adds snarky code comments
FreeBSD kernel is written in C right?
AI bots will trivially find CVEs.
Automatic discovery can be a huge benefit, even if the transition period is scary.
Nevertheless, attacking is a targeted endeavour, unlike defense. Fixing is, in _general_, more difficult in theory.
* reference to past google and ffmpeg incident
https://www.youtube.com/watch?v=1sd26pWhfmg
Looks like LLMs are getting good at finding and exploiting these.
https://xcancel.com/sama/status/2004939524216910323
A theoretical random tweet and a clear demonstration are two different things.
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/
[kmiles@peter ~]$ cat /etc/os-release
NAME=FreeBSD
VERSION="13.3-RELEASE-p4"
VERSION_ID="13.3"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 13.3-RELEASE-p4"
CPE_NAME="cpe:/o:freebsd:freebsd:13.3"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"
[kmiles@peter ~]$ sysctl kern.elf64.aslr.enable
kern.elf64.aslr.enable: 1
I am hoping that quite soon we will have general acceptance of the fact that "Claude can write code" and we will switch focus to how good / not good that code is.
This is what Claude is meant to be able to do.
Preventing it doing so is just security theater.
Here's what I'm referring to: https://github.com/califio/publications/blob/7ed77d11b21db80...
"demon strait". Was this speech to text? That might explain the punctuation and grammar.
https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd
But I found the exploit writeup pretty interesting
Is it possible to pwn without SSH listening?
> Attack surface: NFS server with kgssapi.ko loaded (port 2049/TCP)
Not sure who would run an internet exposed NFS server. Shodan would know.