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.
I see that as a very good thing. Because you can now inexpensively find those CVEs and fix them.
Previously, finding CVEs was very expensive. That meant only bad actors had the incentive to look for them, since they were the ones who could profit from the effort. Now that CVEs can be found much more cheaply, people without a profit motive can discover them as well--allowing vulnerabilities to be fixed before bad actors find them.
Nonsense. Claude did find this CVE and hundreds of similar Linux CVE's, plus it did the complete writeup and the reproducer. The Linux bugs are more worrying. His backlog is hundreds of yet unreported zero days.
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.
> 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?
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.
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.
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?
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.
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.
I could see that being an incremental time save (perhaps not worth the token spend except for the dev team, not a high-value bug). But nbody finds this kind of bug "by hand" and hasn't for a long time now. Do people here really care about kernel security or testing automation? They're just talking about it because Claude? Everything on HN is people doing unpaid promotional work for Anthropic, just talking about all the promise Claude holds and all the various ways you could be spending more money on Claude. bored aimless vibes.
I get what you’re saying, but I think the interesting part isn’t that people don’t find this by hand anymore, it’s that we’re starting to automate finding stuff no one was really catching consistently.
HN hype is definitely real lol, but I don’t think it’s just unpaid promo. People are just trying to figure out where these tools are actually useful and where it’s just vibes.
And “not a high value bug” kinda depends. For product maybe not, but for infra or security, small wins can add up if they scale.
42 comments
[ 3.3 ms ] story [ 93.3 ms ] threadThat 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...
https://www.youtube.com/watch?v=1sd26pWhfmg
Claude is already able to find CVEs on expert level.
It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".
[1] https://news.ycombinator.com/item?id=47589227
[2] https://xbow.com/
Is that a good thing or bad?
I see that as a very good thing. Because you can now inexpensively find those CVEs and fix them.
Previously, finding CVEs was very expensive. That meant only bad actors had the incentive to look for them, since they were the ones who could profit from the effort. Now that CVEs can be found much more cheaply, people without a profit motive can discover them as well--allowing vulnerabilities to be fixed before bad actors find them.
https://red.anthropic.com/2026/zero-days/
He did a talk at unblocked last month.
https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd
But I found the exploit writeup pretty interesting
https://www.youtube.com/watch?v=1sd26pWhfmg
Looks like LLMs are getting good at finding and exploiting these.
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/
Is it possible to pwn without SSH listening?
Automatic discovery can be a huge benefit, even if the transition period is scary.
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.
HN hype is definitely real lol, but I don’t think it’s just unpaid promo. People are just trying to figure out where these tools are actually useful and where it’s just vibes.
And “not a high value bug” kinda depends. For product maybe not, but for infra or security, small wins can add up if they scale.