7 ms·

Claude wrote a full FreeBSD remote kernel RCE with root shell

270 points by ishqdehlvi 6mo ago

PunchyHamster 6mo ago
I'm just gonna assume it was asked to fix some bug and it wrote exploit instead
- xorgun 6mo ago
  [dead]
magicalhippo 6mo ago
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.rpcsec_gss.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08...
- fragmede 6mo 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 6mo 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.
    - xorgun 6mo ago
      [dead]
    - jsnell 6mo 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? https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08... > Credits: Nicholas Carlini using Claude, Anthropic
      - magicalhippo 6mo 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 6mo 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: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg https://securitycryptographywhatever.com/2026/03/25/ai-bug-finding/ https://securitycryptographywhatever.com/2026/03/25/ai-bug-f... It pretty much is just "Claude find me an exploitable 0-day" in a loop.
  - bayindirh 6mo ago
    Yes, that claim needs a source.
- petcat 6mo 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 6mo ago
    The Morris worm lesson is yet to be taken seriously.
    - pitched 6mo ago
      We’re here right now looking at a CVE. That has to count as progress?
- Cloudef 6mo 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 6mo 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.
- ogig 6mo ago
  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.
  - zer00eyz 6mo ago
    It has access to more testing data than I will ever look at. Letting it pull from that knowledge graph is going to give you good results! I just built a chunk of this (type of thinking) into my (now evolving) test harness. 1. Unit testing is (somewhat) dead, long live simulation. Testing the parts only gets you so far. These tests are far more durable, independent artifacts (read, if you went from JS to rust, how much of your testing would carry over) 2. Testing has to be "stand alone". I want to be able to run it from the command line, I want the output to be wrapper so I can shove the output on a web page, or dump it into an API (for AI) 3. Messages (for failures) matter. These are not just simple what's broken, but must contain enough info for context. 4. Your "failed" tests should include logs. Do you have enough breadcrumbs for production? If not, this is a problem that will bite you later. 5. Any case should be an accumulation of state and behavior - this really matters in simulation. If you have done all the above right and your tool can return all the data, dumping the output into the cheapest model you can find and having it "Write a prompt with recommendations on a fix (not actual code, just what should be done beyond "fix this") has been illuminating. Ultimately I realized that how I thought about testing was wrong. Its output should be either dead simple, or have enough information that someone with zero knowledge could ramp up into a fix on their first day in the code base. My testing was never this good because the "cost of doing it that way" was always too high... this is no longer the case.
  - rsync 6mo ago
    [flagged]
    - ogig 6mo ago
      This very question was asked to Nicholas Carlini from Anthropic at this talk: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg The answer is complex, worth watching the video. But mainly, they don't know where to place the line. Defenders need tools, as good as attackers. Attackers will jailbreak models, defender might not, it's the safeguard positive in that case? Carlini actively asks the audience and community for "help" in determining how to proceed basically.
- muskstinks 6mo ago
  You might want to watch this: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Claude is already able to find CVEs on expert level.
  - deleted 6mo ago
    [deleted]
  - shimman 6mo 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.
    - muskstinks 6mo 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 6mo ago
        But you did say “Claude is already able to find CVEs on expert level.”
        muskstinks 6mo 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
        ale 6mo ago
        Haha alright good point
    - pama 6mo ago
      It is by the individual who (also with Claude) found the specific vulnerability used in this exploit.
- Foobar8568 6mo ago
  Look at Xbow which spawned a few "open source" competitors.
- cryptbe 6mo 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".
  - magicalhippo 6mo ago
    [flagged]
- mentalgear 6mo ago
  [flagged]
  - Isamu 6mo ago
    Everything with LLM-style AI is brute force. I don’t think people care, unless there’s a new data center going in next door that’s incredibly resource inefficient .
  - margalabargala 6mo ago
    Brute force might be dismissed as "not elegant" but it's highly effective. Especially for bypassing security. If you need to access someone's account or decrypt their hard drive, brute force is an effective way to do it.
- wslh 6mo ago
  While it's great to clarify, LLMs are actually finding bugs and writing exploits [1][2]. There are more example though. [1] https://news.ycombinator.com/item?id=47589227 https://news.ycombinator.com/item?id=47589227 [2] https://xbow.com/ https://xbow.com/
  - giancarlostoro 6mo ago
    Another great example is how Claude is helping Mozilla find zero day exploits in Firefox, by the hundreds, and ranging from minor to CVE level, for over a year: https://blog.mozilla.org/en/firefox/hardening-firefox-anthropic-red-team/ https://blog.mozilla.org/en/firefox/hardening-firefox-anthro... I think the Mozilla example is a good one because its a large codebase, lots of people keep asking "how does it do with a large codebase" well there you go.
    - wslh 6mo ago
      And you can check the list of bugs being discovered by Anthropic's Red Team: https://red.anthropic.com/ https://red.anthropic.com/
- lateforwork 6mo ago
  > get it pumping out CVEs. 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.
  - cogman10 6mo ago
    It's good and bad. Not all CVEs are the same, some aren't important. So it really depends on what gets founds as a CVE. The bad part is you risk a flood a CVEs that don't matter (or have already been reported). > That meant only bad actors had the incentive to look for them Nah. Lot's of people look for CVEs. It's good resume fodder. In fact, it's already somewhat of a problem that people will look for and report CVEs on things that don't matter just so they can get the "I found and reported CVE xyz" on their resume. What this will do is expose some already present flaws in the CVE scoring system. Not all "9"s are created equal. Hopefully that leads to something better and not towards apathy.
    - evanmoran 6mo ago
      It also depends on if the CVEs can be fixed by LLMs too. If they can find and fix them, then it's very good.
      - cogman10 6mo ago
        Fixing isn't often a problem for CVEs. The hard part is almost always finding the CVE in the first place. There are some extreme cases that might require extensive code changes, and those would benefit from LLMs. But a lot of the issues are things like off by one issues with pointers.
        wepple 6mo ago
        Fixing is now the bottleneck. Most patches are non-trivial and then each project/maintainer has a preferred coding style, and they’re being inundated with PRs already, and don’t take kindly to slop. LLMs can find the CVE fully zero interaction, so it scales trivially.
- themafia 6mo ago
  They tried. It didn't work that well: https://red.anthropic.com/2026/zero-days/ https://red.anthropic.com/2026/zero-days/
  - joe_mamba 6mo ago
    How did you managed to get it to do that? When I gave it instructions to use Ghidra MCP to look for vulnerabilities in a windows driver on my local machine it refused saying it's not allowed to do pentest activities even if sandboxed to your own device.
    - tonyarkles 6mo ago
      Not who you were asking and not explicitly looking for vulnerabilities... I have gotten a ton of mileage from getting Claude to reverse engineer both firmware and applications with Ghidra and radare2. My usual prompt starts with "Here's the problem I'm having [insert problem]. @foo.exe is the _installer for the latest firmware update_. Extract the firmware and determine if there's a plausible path that could cause this problem. Document how you've extracted the firmware, how you've done the analysis, and the ultimate conclusions in @this-markdown-file.md" I have gotten absolutely incredible results out of it. I have had a few hallucinations/incorrect analyses (hard to tell which it was), but in general the results have been fantastic. The closest I've come to security vulnerabilities was a Bluetooth OBD-II reader. I gave Claude the APK and asked it to reverse engineer the BLE protocol so that I could use the device from Python. There was apparently a ton of obfuscation in the APK, with the actual BLE logic buried inside an obfuscated native code library instead of Java code. Claude eventually asked me to install the Android emulator so that it could use https://frida.re https://frida.re to do dynamic instrumentation instead of relying entirely on static analysis. The output was impressive.
  - tptacek 6mo ago
    Sorry, can you clarify what you're saying here? What didn't work that well?
    - themafia 6mo ago
- rurban 6mo ago
  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. He did a talk at unblocked last month.
  - rurban 6mo ago
    Not unblocked but unprompted: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Great talk.
rithdmc 6mo 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.
fragmede 6mo ago
https://github.com/califio/publications/tree/main/MADBugs/CVE-2026-4747 https://github.com/califio/publications/tree/main/MADBugs/CV... would have been a better link
- tln 6mo ago
  Or even better, the blog post. https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd But I found the exploit writeup pretty interesting
m132 6mo ago
Appreciate the full prompt history
- ptx 6mo 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.
  - dboreham 6mo ago
    fwiw you can dump the actual session in a format suitable to be posted on the web with this tool: https://simonwillison.net/2025/Dec/25/claude-code-transcripts/ https://simonwillison.net/2025/Dec/25/claude-code-transcript...
- dark-star 6mo ago
  [flagged]
  - addandsubtract 6mo 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_ 6mo ago
      Just think about how your parents used google when you were a kid. What got better results faster?
      - nunez 6mo ago
        we were taught google search query syntax by our librarian when I was in high school in 2002-ish. so...
panstromek 6mo ago
The talk "Black-Hat LLMs" just came out a few days ago: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Looks like LLMs are getting good at finding and exploiting these.
- baq 6mo 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. https://xcancel.com/sama/status/2004939524216910323 https://xcancel.com/sama/status/2004939524216910323
  - eru 6mo ago
    I never read any Twitter.
    - baq 6mo ago
      X was the primary source, it's been since reported all over the news.
  - muskstinks 6mo ago
    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.
ptx 6mo 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? NetBSD apparently has it: https://wiki.netbsd.org/security/kaslr/ https://wiki.netbsd.org/security/kaslr/
- keysersoze33 6mo 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-security-from-grsecurity-member.56298/ https://forums.freebsd.org/threads/truth-about-linux-4-6-sec...
  - pixl97 6mo ago
    Security is an onion, honestly you want both layers to be as hard as possible.
- ktm5j 6mo ago
  I don't understand this, because KASLR has been default in FreeBSD since 13.2: [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/ https://FreeBSD.org/" BUG_REPORT_URL="https://bugs.FreeBSD.org/ https://bugs.FreeBSD.org/" [kmiles@peter ~]$ sysctl kern.elf64.aslr.enable kern.elf64.aslr.enable: 1
  - savant2 6mo ago
    This knob isn't KASLR, it just enables ASLR for ELF binaries.
Adam_cipher 6mo ago
[flagged]
sheepscreek 6mo 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.
dheerajmp 6mo ago
You do not need Claude for finding FreeBSD vulns. Just plain eyes. Pick a file you can find one.
jeremie_strand 6mo ago
[dead]
dnw 6mo ago
Thanks for sharing the prompts: https://github.com/califio/publications/blob/main/MADBugs/CVE-2026-4747/claude-prompts.txt https://github.com/califio/publications/blob/main/MADBugs/CV...
- stek29 6mo ago
  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.
bustah 6mo ago
[flagged]
- MYEUHD 6mo ago
  This is an AI-generated comment.
alcor-z 6mo 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 6mo 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 6mo ago
    You also need a valid Kerberos ticket to get to the point where you can exploit.
- astrange 6mo ago
  This post is AI slop.
volume_tech 6mo ago
[flagged]
imta71770 6mo ago
[dead]
htx80nerd 6mo ago
[flagged]
EGreg 6mo ago
This requires an SSH to be available? Is it possible to pwn without SSH listening?
- fragmede 6mo ago
  *NFS
  - bink 6mo ago
    One of the exploits writes a public key to the authorized_keys file, so it does require SSH be open as well.
- jeremie_strand 6mo ago
  [dead]
stephc_int13 6mo 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 6mo 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
neonstatic 6mo 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.
- abcde666777 6mo ago
  Read my mind. I want to see what it got right and wrong, whether it's an absolute mess or actually maintainable over time, etc.
andrewstuart 6mo 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.
jdurban 6mo ago
[flagged]
- samtheprogram 6mo ago
  As mentioned elsewhere, while this writeup is about exploiting the RCE, Claude was separately used to find and document this specific RCE.
  - jdurban 6mo ago
    [flagged]
aplomb1026 6mo ago
[dead]
imta71770 6mo ago
[dead]
decidu0us9034 6mo ago
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.
- josephismikhail 6mo ago
  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.
tptacek 6mo ago
Calif (Thai Duong's firm) did a writeup on this, which should probably be the link here; it includes the prompts they used: https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd A reminder: this bug was also found by Claude (specifically, by Nicholas Carlini at Anthropic).
yumiatlead 6mo ago
This showcases the immense power and autonomy of agents, which is the root of enterprise fear. It highlights the urgent need for governance and safety.
navilai 6mo ago
[dead]
a96 6mo ago
Ah, RPC. The gift that keeps on giving even after 30 years of security fails.

270 points by ishqdehlvi 6mo ago

PunchyHamster 6mo ago

I'm just gonna assume it was asked to fix some bug and it wrote exploit instead

xorgun 6mo ago
[dead]

magicalhippo 6mo ago

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.rpcsec_gss.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08...

fragmede 6mo 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 6mo 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.
  - xorgun 6mo ago
    [dead]
  - jsnell 6mo 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? https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08... > Credits: Nicholas Carlini using Claude, Anthropic
    - magicalhippo 6mo 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 6mo 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: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg https://securitycryptographywhatever.com/2026/03/25/ai-bug-finding/ https://securitycryptographywhatever.com/2026/03/25/ai-bug-f... It pretty much is just "Claude find me an exploitable 0-day" in a loop.
- bayindirh 6mo ago
  Yes, that claim needs a source.
petcat 6mo 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 6mo ago
  The Morris worm lesson is yet to be taken seriously.
  - pitched 6mo ago
    We’re here right now looking at a CVE. That has to count as progress?
Cloudef 6mo 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 6mo 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.
ogig 6mo ago
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.
- zer00eyz 6mo ago
  It has access to more testing data than I will ever look at. Letting it pull from that knowledge graph is going to give you good results! I just built a chunk of this (type of thinking) into my (now evolving) test harness. 1. Unit testing is (somewhat) dead, long live simulation. Testing the parts only gets you so far. These tests are far more durable, independent artifacts (read, if you went from JS to rust, how much of your testing would carry over) 2. Testing has to be "stand alone". I want to be able to run it from the command line, I want the output to be wrapper so I can shove the output on a web page, or dump it into an API (for AI) 3. Messages (for failures) matter. These are not just simple what's broken, but must contain enough info for context. 4. Your "failed" tests should include logs. Do you have enough breadcrumbs for production? If not, this is a problem that will bite you later. 5. Any case should be an accumulation of state and behavior - this really matters in simulation. If you have done all the above right and your tool can return all the data, dumping the output into the cheapest model you can find and having it "Write a prompt with recommendations on a fix (not actual code, just what should be done beyond "fix this") has been illuminating. Ultimately I realized that how I thought about testing was wrong. Its output should be either dead simple, or have enough information that someone with zero knowledge could ramp up into a fix on their first day in the code base. My testing was never this good because the "cost of doing it that way" was always too high... this is no longer the case.
- rsync 6mo ago
  [flagged]
  - ogig 6mo ago
    This very question was asked to Nicholas Carlini from Anthropic at this talk: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg The answer is complex, worth watching the video. But mainly, they don't know where to place the line. Defenders need tools, as good as attackers. Attackers will jailbreak models, defender might not, it's the safeguard positive in that case? Carlini actively asks the audience and community for "help" in determining how to proceed basically.
muskstinks 6mo ago
You might want to watch this: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Claude is already able to find CVEs on expert level.
- deleted 6mo ago
  [deleted]
- shimman 6mo 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.
  - muskstinks 6mo 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 6mo ago
      But you did say “Claude is already able to find CVEs on expert level.”
      - muskstinks 6mo 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
        ale 6mo ago
        Haha alright good point
  - pama 6mo ago
    It is by the individual who (also with Claude) found the specific vulnerability used in this exploit.
Foobar8568 6mo ago
Look at Xbow which spawned a few "open source" competitors.
cryptbe 6mo 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".
- magicalhippo 6mo ago
  [flagged]
mentalgear 6mo ago
[flagged]
- Isamu 6mo ago
  Everything with LLM-style AI is brute force. I don’t think people care, unless there’s a new data center going in next door that’s incredibly resource inefficient .
- margalabargala 6mo ago
  Brute force might be dismissed as "not elegant" but it's highly effective. Especially for bypassing security. If you need to access someone's account or decrypt their hard drive, brute force is an effective way to do it.
wslh 6mo ago
While it's great to clarify, LLMs are actually finding bugs and writing exploits [1][2]. There are more example though. [1] https://news.ycombinator.com/item?id=47589227 https://news.ycombinator.com/item?id=47589227 [2] https://xbow.com/ https://xbow.com/
- giancarlostoro 6mo ago
  Another great example is how Claude is helping Mozilla find zero day exploits in Firefox, by the hundreds, and ranging from minor to CVE level, for over a year: https://blog.mozilla.org/en/firefox/hardening-firefox-anthropic-red-team/ https://blog.mozilla.org/en/firefox/hardening-firefox-anthro... I think the Mozilla example is a good one because its a large codebase, lots of people keep asking "how does it do with a large codebase" well there you go.
  - wslh 6mo ago
    And you can check the list of bugs being discovered by Anthropic's Red Team: https://red.anthropic.com/ https://red.anthropic.com/
lateforwork 6mo ago
> get it pumping out CVEs. 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.
- cogman10 6mo ago
  It's good and bad. Not all CVEs are the same, some aren't important. So it really depends on what gets founds as a CVE. The bad part is you risk a flood a CVEs that don't matter (or have already been reported). > That meant only bad actors had the incentive to look for them Nah. Lot's of people look for CVEs. It's good resume fodder. In fact, it's already somewhat of a problem that people will look for and report CVEs on things that don't matter just so they can get the "I found and reported CVE xyz" on their resume. What this will do is expose some already present flaws in the CVE scoring system. Not all "9"s are created equal. Hopefully that leads to something better and not towards apathy.
  - evanmoran 6mo ago
    It also depends on if the CVEs can be fixed by LLMs too. If they can find and fix them, then it's very good.
    - cogman10 6mo ago
      Fixing isn't often a problem for CVEs. The hard part is almost always finding the CVE in the first place. There are some extreme cases that might require extensive code changes, and those would benefit from LLMs. But a lot of the issues are things like off by one issues with pointers.
      - wepple 6mo ago
        Fixing is now the bottleneck. Most patches are non-trivial and then each project/maintainer has a preferred coding style, and they’re being inundated with PRs already, and don’t take kindly to slop. LLMs can find the CVE fully zero interaction, so it scales trivially.
themafia 6mo ago
They tried. It didn't work that well: https://red.anthropic.com/2026/zero-days/ https://red.anthropic.com/2026/zero-days/
- joe_mamba 6mo ago
  How did you managed to get it to do that? When I gave it instructions to use Ghidra MCP to look for vulnerabilities in a windows driver on my local machine it refused saying it's not allowed to do pentest activities even if sandboxed to your own device.
  - tonyarkles 6mo ago
    Not who you were asking and not explicitly looking for vulnerabilities... I have gotten a ton of mileage from getting Claude to reverse engineer both firmware and applications with Ghidra and radare2. My usual prompt starts with "Here's the problem I'm having [insert problem]. @foo.exe is the _installer for the latest firmware update_. Extract the firmware and determine if there's a plausible path that could cause this problem. Document how you've extracted the firmware, how you've done the analysis, and the ultimate conclusions in @this-markdown-file.md" I have gotten absolutely incredible results out of it. I have had a few hallucinations/incorrect analyses (hard to tell which it was), but in general the results have been fantastic. The closest I've come to security vulnerabilities was a Bluetooth OBD-II reader. I gave Claude the APK and asked it to reverse engineer the BLE protocol so that I could use the device from Python. There was apparently a ton of obfuscation in the APK, with the actual BLE logic buried inside an obfuscated native code library instead of Java code. Claude eventually asked me to install the Android emulator so that it could use https://frida.re https://frida.re to do dynamic instrumentation instead of relying entirely on static analysis. The output was impressive.
- tptacek 6mo ago
  Sorry, can you clarify what you're saying here? What didn't work that well?
  - themafia 6mo ago
rurban 6mo ago
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. He did a talk at unblocked last month.
- rurban 6mo ago
  Not unblocked but unprompted: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Great talk.

rithdmc 6mo 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.

fragmede 6mo ago

https://github.com/califio/publications/tree/main/MADBugs/CVE-2026-4747 https://github.com/califio/publications/tree/main/MADBugs/CV... would have been a better link

tln 6mo ago
Or even better, the blog post. https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd But I found the exploit writeup pretty interesting

m132 6mo ago

Appreciate the full prompt history

ptx 6mo 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.
- dboreham 6mo ago
  fwiw you can dump the actual session in a format suitable to be posted on the web with this tool: https://simonwillison.net/2025/Dec/25/claude-code-transcripts/ https://simonwillison.net/2025/Dec/25/claude-code-transcript...
dark-star 6mo ago
[flagged]
- addandsubtract 6mo 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_ 6mo ago
    Just think about how your parents used google when you were a kid. What got better results faster?
    - nunez 6mo ago
      we were taught google search query syntax by our librarian when I was in high school in 2002-ish. so...

panstromek 6mo ago

The talk "Black-Hat LLMs" just came out a few days ago: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Looks like LLMs are getting good at finding and exploiting these.

baq 6mo 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. https://xcancel.com/sama/status/2004939524216910323 https://xcancel.com/sama/status/2004939524216910323
- eru 6mo ago
  I never read any Twitter.
  - baq 6mo ago
    X was the primary source, it's been since reported all over the news.
- muskstinks 6mo ago
  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.

ptx 6mo 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? NetBSD apparently has it: https://wiki.netbsd.org/security/kaslr/ https://wiki.netbsd.org/security/kaslr/

keysersoze33 6mo 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-security-from-grsecurity-member.56298/ https://forums.freebsd.org/threads/truth-about-linux-4-6-sec...
- pixl97 6mo ago
  Security is an onion, honestly you want both layers to be as hard as possible.
ktm5j 6mo ago
I don't understand this, because KASLR has been default in FreeBSD since 13.2: [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/ https://FreeBSD.org/" BUG_REPORT_URL="https://bugs.FreeBSD.org/ https://bugs.FreeBSD.org/" [kmiles@peter ~]$ sysctl kern.elf64.aslr.enable kern.elf64.aslr.enable: 1
- savant2 6mo ago
  This knob isn't KASLR, it just enables ASLR for ELF binaries.

Adam_cipher 6mo ago

[flagged]

sheepscreek 6mo 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.

dheerajmp 6mo ago

You do not need Claude for finding FreeBSD vulns. Just plain eyes. Pick a file you can find one.

jeremie_strand 6mo ago

[dead]

dnw 6mo ago

Thanks for sharing the prompts: https://github.com/califio/publications/blob/main/MADBugs/CVE-2026-4747/claude-prompts.txt https://github.com/califio/publications/blob/main/MADBugs/CV...

stek29 6mo ago
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.

bustah 6mo ago

[flagged]

MYEUHD 6mo ago
This is an AI-generated comment.

alcor-z 6mo 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 6mo 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 6mo ago
  You also need a valid Kerberos ticket to get to the point where you can exploit.
astrange 6mo ago
This post is AI slop.

volume_tech 6mo ago

[flagged]

imta71770 6mo ago

[dead]

htx80nerd 6mo ago

[flagged]

EGreg 6mo ago

This requires an SSH to be available? Is it possible to pwn without SSH listening?

fragmede 6mo ago
*NFS
- bink 6mo ago
  One of the exploits writes a public key to the authorized_keys file, so it does require SSH be open as well.
jeremie_strand 6mo ago
[dead]

stephc_int13 6mo 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 6mo 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

neonstatic 6mo 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.

abcde666777 6mo ago
Read my mind. I want to see what it got right and wrong, whether it's an absolute mess or actually maintainable over time, etc.

andrewstuart 6mo 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.

jdurban 6mo ago

[flagged]

samtheprogram 6mo ago
As mentioned elsewhere, while this writeup is about exploiting the RCE, Claude was separately used to find and document this specific RCE.
- jdurban 6mo ago
  [flagged]

aplomb1026 6mo ago

[dead]

imta71770 6mo ago

[dead]

decidu0us9034 6mo ago

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.

josephismikhail 6mo ago
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.

tptacek 6mo ago

Calif (Thai Duong's firm) did a writeup on this, which should probably be the link here; it includes the prompts they used: https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd A reminder: this bug was also found by Claude (specifically, by Nicholas Carlini at Anthropic).

yumiatlead 6mo ago

This showcases the immense power and autonomy of agents, which is the root of enterprise fear. It highlights the urgent need for governance and safety.

navilai 6mo ago

[dead]

a96 6mo ago

Ah, RPC. The gift that keeps on giving even after 30 years of security fails.