7 ms·

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 sa

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 7mo 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 7mo 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 7mo ago
    [dead]
  - jsnell 7mo 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 7mo 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 7mo 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 7mo ago
  Yes, that claim needs a source.
petcat 7mo 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 7mo ago
  The Morris worm lesson is yet to be taken seriously.
  - pitched 7mo ago
    We’re here right now looking at a CVE. That has to count as progress?
Cloudef 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
  [flagged]
  - ogig 7mo 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 7mo 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 7mo ago
  [deleted]
- shimman 7mo 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 7mo 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 7mo ago
      But you did say “Claude is already able to find CVEs on expert level.”
      - muskstinks 7mo 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 7mo ago
        Haha alright good point
  - pama 7mo ago
    It is by the individual who (also with Claude) found the specific vulnerability used in this exploit.
Foobar8568 7mo ago
Look at Xbow which spawned a few "open source" competitors.
cryptbe 7mo 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 7mo ago
  [flagged]
mentalgear 7mo ago
[flagged]
- Isamu 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
  Sorry, can you clarify what you're saying here? What didn't work that well?
  - themafia 7mo ago
rurban 7mo 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 7mo ago
  Not unblocked but unprompted: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Great talk.

fragmede 7mo 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 7mo 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 7mo ago
  [dead]
- jsnell 7mo 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 7mo 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 7mo 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 7mo ago
Yes, that claim needs a source.

petcat 7mo 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 7mo ago
The Morris worm lesson is yet to be taken seriously.
- pitched 7mo ago
  We’re here right now looking at a CVE. That has to count as progress?

Cloudef 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
[flagged]
- ogig 7mo 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 7mo 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 7mo ago
[deleted]
shimman 7mo 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 7mo 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 7mo ago
    But you did say “Claude is already able to find CVEs on expert level.”
    - muskstinks 7mo 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 7mo ago
        Haha alright good point
- pama 7mo ago
  It is by the individual who (also with Claude) found the specific vulnerability used in this exploit.

Foobar8568 7mo ago

Look at Xbow which spawned a few "open source" competitors.

cryptbe 7mo 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 7mo ago
[flagged]

mentalgear 7mo ago

[flagged]

Isamu 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
Sorry, can you clarify what you're saying here? What didn't work that well?
- themafia 7mo ago

rurban 7mo 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 7mo ago
Not unblocked but unprompted: https://www.youtube.com/watch?v=1sd26pWhfmg https://www.youtube.com/watch?v=1sd26pWhfmg Great talk.