Key point is that Claude did not <i>find</i> the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug.<p>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.<p>If not now, then surely not in a too distant future.<p>[1]: <a href="https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc" rel="nofollow">https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08...</a>
> Credits: Nicholas Carlini using Claude, Anthropic<p>Claude was used to <i>find</i> 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.
> Claude was used to find the bug in the first place though. That CVE write-up happened because of Claude<p>Do you have a link to that? A rather important piece of context.<p>Wasn't trying to downplay this submission the way, the main point still stands:<p><i>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.<p>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.</i>
> 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.<p>FreeBSD kernel is written in C right?<p>AI bots will trivially find CVEs.
> <i>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[]).</i><p>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?<p>NetBSD apparently has it: <a href="https://wiki.netbsd.org/security/kaslr/" rel="nofollow">https://wiki.netbsd.org/security/kaslr/</a>
The talk "Black-Hat LLMs" just came out a few days ago:<p><a href="https://www.youtube.com/watch?v=1sd26pWhfmg" rel="nofollow">https://www.youtube.com/watch?v=1sd26pWhfmg</a><p>Looks like LLMs are getting good at finding and exploiting these.
Appreciate the full prompt history
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 read like they were done by a 10 year old
I'm just gonna assume it was asked to fix some bug and it wrote exploit instead
<a href="https://github.com/califio/publications/tree/main/MADBugs/CVE-2026-4747" rel="nofollow">https://github.com/califio/publications/tree/main/MADBugs/CV...</a> would have been a better link
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.