8 ms·

Vulnerability research is cooked

267 points by pedro84 6mo ago

deleted 6mo ago
[deleted]
ronnier 6mo ago
[dead]
nitros 6mo ago
I'm suspicious of this prediction given the curl project's experiences...
- tptacek 6mo ago
  Everybody agrees that idiots were spamming curl with random just-plausible-enough-seeming output from old models.
  - tomjakubowski 6mo ago
    It sounds like what makes the pipeline in the article effective is the second stage, which takes in the vulnerability reports produced by the first level and confirms or rejects them. The article doesn't say what the rejection rate is there. I don't think the spammers would think to write the second layer, they would most likely pipe the first layer (a more naive version of it too, probably) directly to the issue feed.
    - tptacek 6mo ago
      There are at least three differences: * Carlini's team used new frontier models that have gotten materially better at finding vulnerabilities (talk to vulnerability researchers outside the frontier labs, they'll echo that). Stenberg was getting random slop from people using random models. * Carlini's process is iterated exhaustively over the whole codebase; he's not starting with a repo and just saying "find me an awesome bug" and taking that and only that forward in the process. * And then yes, Carlini is qualifying the first-pass findings with a second pass.
      - tomjakubowski 6mo ago
        Thanks, I hadn't considered the second point. I guess the broader point I wanted to make is about the people responsible for the deluge of LLM-reported bugs and security vulnerabilities on countless open-source projects (not only on curl): they weren't considerate or thoughtful security researchers, they were spammers looking to raise their profile with fully automated, hands-off open source "contributions". I would expect that the spammers would continue to use whatever lowest common denominator tooling is available, and continue to cause these headaches for maintainers. That doesn't mean frontier models and tooling built around them aren't genuinely useful to people doing serious security research: that does seem to be the case, and I'm glad for it.
- wslh 6mo ago
  The problem is that you have all kind of "security spam" in the same way that social media is flooded by automatic, but on-topic, content. This doesn't mean that some very few reports are not correct. One way to filter that out could be to receive the PoC of the exploit, and test it in some sandbox. I think what XBOW and others are doing is real.
- jerf 6mo ago
  The people spamming curl did step one, "write me a vulnerability report on X" but skipped step two, "verify for me that it's actually exploitable". Tack on a step three where a reasonably educated user in the field of security research does a sanity check on the vulnerability implementation as well and you'll have a pipeline that doesn't generate a ton of false positives. The question then will rather be how cost-effective it is for the tokens and the still-non-zero human time involved.
- MajesticHobo2 6mo ago
  That was then, this is now. The new models are scarily good. If you're skeptical, just take an hour to replicate the strategy the article references. Point Claude at any open-source codebase you find interesting and instruct it to find exploitable vulnerabilities. Give it a well-defined endpoint if you want (e.g., "You must develop a Python script that triggers memory corruption via a crafted request") and see how well it does.
  - phyzome 6mo ago
    > That was then, this is now. No, what we were seeing with curl was script kiddies. It wasn't about the quality of the models at all. They were not filtering their results for validity.
    - MajesticHobo2 6mo ago
      It was definitely partially about model quality. The frontier models are capable of producing valid findings with (reasonably) complex exploit chains on the first pass (or with limited nudging) and are much less prone to making up the kinds of nonsensical reports that were submitted to curl. Compared to now, the old models essentially didn't work for security. If those script kiddies had been using today's models instead and _still_ didn't do any filtering, a lot more of those bugs would have been true positives.
- gsnedders 6mo ago
  To some extent, that’s just the nature of the incentive structure — you pay money for exploits with no penalty for false reports? Just rely on monkeys typing reports till one happens to be correct.
tomjakubowski 6mo ago
> Now consider the poor open source developers who, for the last 18 months, have complained about a torrent of slop vulnerability reports. I’d had mixed sympathies, but the complaints were at least empirically correct. That could change real fast. The new models find real stuff. The slop reports won't stop just because real ones are coming in. If the author's right, open source maintainers will still will have to deal with the torrent of slop: on top of triaging and identifying the legit vulnerabilities. Obviously, this is just another role for AI models to fill.
badgersnake 6mo ago
Another boring AI hype article. “The next model will be the one. Trust me. Just one more iteration.”
- deleted 6mo ago
  [deleted]
stavros 6mo ago
I don't understand why the takeaway here is (unless I'm missing something), more or less "everything is going to get exploited all the time". If LLMs can really find a ton of vulnerabilities in my software, why would I not run them and just patch all the vulnerabilities, leading to perfectly secure software (or, at the very least, software for which LLMs can no longer find any new vulnerabilities)?
- tptacek 6mo ago
  That might be one outcome, especially for large, expertly-staffed vendors who are already on top of this stuff. My real interest in what happens to the field for vulnerability researchers.
  - stavros 6mo ago
    True, but I already am curious to see what happens in a multitude of fields, so this is just one more entry in that list.
  - lifty 6mo ago
    Perhaps a meta evolution, they become experts at writing harnesses and prompts for discovering and patching vulnerabilities in existing code and software. My main interest is, now that we have LLMs, will the software industry move to adopting techniques like formal verification and other perhaps more lax approaches that massively increase the quality of software.
    - habinero 6mo ago
      Testing exists. > formal verification Outside of limited specific circumstances, formal verification gives you nothing that tests don't give you, and it makes development slow and iteration a chore. People know about it, and it's not used for lot of reasons.
      - threethirtytwo 6mo ago
        This statement shows an intense lack of technical knowledge. You’re probably one of those ignorant managerial types. First type checking is a form of formal verification and it’s used everywhere. Second have you heard of rust? Do you know why it’s becoming an alternative to C++ or C? Entirely because of its type checker or aka formal verification. It is the literal main reason why rust was created. Have you heard of typescript? It’s essentially a formal verification layer over JavaScript. Everyone uses it now for the front end. You don’t know what you’re talking about. I recommend you do some research before saying anything on this site.
spr-alex 6mo ago
I interned for the author at 18. I assumed security testing worked like this: 1. Static analysis catches nearly all bugs with near-total code coverage 2. Private tooling extends that coverage further with better static analysis and dynamic analysis, and that edge is what makes contractors valuable 3. Humans focus on design flaws and weird hardware bugs like cryptographic side-channels from electromagnetic emanations Turns out finding all the bugs is really hard. Codebases and compiler output have exploded in complexity over 20 years which has not helped the static analysis vision. Todays mitigations are fantastic compared to then, but just this month a second 0day chain got patched on one of the best platforms for hardware mitigations. I think LLMs get us meaningfully closer to what I thought this work already was when I was 18 and didn't know anything.
- cartoonworld 6mo ago
  lots of security issues form at the boundaries between packages, zones, services, sessions, etc. Static analysis could but doesn't seem to catch this stuff from my perspective. Bugs are often chains and that requires a lot of creativity, planning etc consider logic errors and race conditions. Its surely not impossible for llm to find these, but it seems likely that you'll need to step throught the program control flow in order to reveal a lot of these interactions. I feel like people consider LLM as free since there isn't as much hand-on-keyboard. I kinda disgree, and when the cost of paying out these vulns falls, I feel like nobody is gonna wanna eat the token spend. Plenty of hackers already use ai in their workflows, even then it is a LOT OF WORK.
- Legend2440 6mo ago
  Catching all bugs with static analysis would involve solving the halting problem, so it's never going to happen.
  - MeetingsBrowser 6mo ago
    Catching all bugs with static analysis is actually really easy, as long as you don't mind false positives.
deleted 6mo ago
[deleted]
streetfighter64 6mo ago
> Is the Linux KVM hypervisor connected to the hrtimer subsystem, workqueue, or perf_event? The model knows. I asked ChatGPT and it claimed "all three". Any linux wizards who can confirm or deny? Anyway, in my experience using mainly the Claude chat to do some basic (not security) bug hunting, it usually fixates on one specific hypothesis, and it takes some effort to get it off that wrong track, even when I already know it's barking up the wrong tree.
- tptacek 6mo ago
  It's all three, I just had it on the brain when I was writing this.
  - streetfighter64 6mo ago
    Hm, kind of a strange question then, no? Is a car's engine connected to the fuel tank, the wheels or the accelerator pedal?
    - tptacek 6mo ago
      I don't know, maybe it is? My point is just that frontier models start off with latent models of all the interconnectivity in all the important open-source codebases, to a degree that would be infeasible for the people who learned how all the CSS object lifecycles and image rendering and unicode shaping stuff worked well enough to use them in exploits.
- jgeralnik 6mo ago
  The wonderful thing though is that you can just run the model multiple times (even in parallel). Some instances might get stuck but as long as some find the bug and you have a good way to filter outputs (e.g. with another llm that tries to create concrete exploits) even a very small success rate on stage 1 can lead to reliable exploits
staticassertion 6mo ago
> Everything is up in the air. The industry is sold on memory-safe software, but the shift is slow going. We’ve bought time with sandboxing and attack surface restriction. How well will these countermeasures hold up? A 4 layer system of sandboxes, kernels, hypervisors, and IPC schemes are, to an agent, an iterated version of the same problem. Agents will generate full-chain exploits, and they will do so soon. I think this is the interesting bit. We have some insanely powerful isolation technology and mitigations. I can put a webassembly program into a seccomp'd wrapper in an unprivileged user into a stripped down Linux environment inside of Firecracker. An attacker breaking out of that feels like science fiction to me. An LLM could do it but I think "one shots" for this sort of attack are extremely unlikely today. The LLM will need to find a wasm escape, then a Linux LPE that's reachable from an unprivileged user with a seccomp filter, then once they have kernel control they'll need to manipulate the VM state or attack KVM directly. A human being doing those things is hard to imagine. Exploitation of Firecracker is, from my view, extremely difficult. The bug density is very low - code quality is high and mitigation adoption is a serious hurdle. Obviously people aren't just going to deploy software the way I'm suggesting, but even just "I use AWS Fargate" is a crazy barrier that I'm skeptical an LLM will cross. > Meanwhile, no defense looks flimsier now than closed source code. Interesting, I've had sort of the opposite view. Giving an LLM direct access to the semantic information of your program, the comments, etc, feels like it's just handing massive amounts of context over. With decompilation I think there's a higher risk of it missing the intention of the code. edit: I want to also note that with LLMs I have been able to do sort of insane things. A little side project I have uses iframe sandboxing insanely aggressively. Most of my 3rd party dependencies are injected into an iframe, and the content is rendered in that iframe. It can communicate to the parent over a restricted MessageChannel. For cases like "render markdown" I can even leverage a total-blocking CSP within the sandbox. Writing this by hand would be silly, I can't do it - it's like building an RPC for every library I use. "Resize the window" or "User clicked this link" etc all have to be written individually. But with an LLM I'm getting sort of silly levels of safety here - Chrome is free to move each iframe into its own process, I get isolated origins, I'm immune from supply chain vulnerabilities, I'm immune to mostly immune to XSS (within the frame, where most of the opportunity is) and CSRF is radically harder, etc. LLMs have made adoption of Trusted Types and other mitigations insanely easy for me and, IMO, these sorts of mitigations are more effective at preventing attacks than LLMs will be at finding bypasses (contentious and platform dependent though!). I suppose this doesn't have any bearing on the direct position of the blog post, which is scoped to the new role for vulnerability research, but I guess my interest is obviously going to be more defense oriented as that's where I live :)
rubiquity 6mo ago
I was distracted by the picture of the ingredients to a Final Ward being at the top of the page.
narginal 6mo ago
Just like how fuzzers will find all the bugs, right? Right?? There's definitely infrastructure at these big companies that isn't sitting in a while loop 'fuzzing' right? Why is it news that vulnerability research will continue to get harder, exactly? It has always been this way, exploits will get more expensive, and the best researchers will continue with whatever tools they find useful.
- tptacek 6mo ago
  It's a good question. Fuzzers generated a surge of new vulnerabilities, especially after institutional fuzzing clusters got stood up, and after we converged on coverage-guided fuzzers like AFL. We then got to a stable equilibrium, a new floor, such that vulnerability research & discovery doesn't look that drastically different after fuzzing as before. Two things to notice: * First, fuzzers also generated and continue to generate large stacks of unverified crashers, such that you can go to archives of syzkaller crashes and find crashers that actually work. My contention is that models are not just going to produce hypothetical vulnerabilities, but also working exploits. * Second, the mechanism 4.6 and Codex are using to find these vulnerabilities is nothing like that of a fuzzer. A fuzzer doesn't "know" it's found a vulnerability; it's a simple stimulus/response test (sequence goes in, crash does/doesn't come out). Most crashers aren't exploitable. Models can use fuzzers to find stuff, and I'm surprised that (at least for Anthropic's Red Team) that's not how they're doing it yet. But at least as I understand it, that's generally not what they're doing. It something much closer to static analysis.
  - staticassertion 6mo ago
    I suspect we'll see combinations of symbolic execution + fuzzing as contextual inputs to LLMs, with LLMs delegating highly directed tasks to these external tools that are radically faster at exploring a space with the LLM guiding based on its own semantic understanding of the code. I'm with you, I expected this to be happening already. Funny enough, I guess even a hardened codebase isn't at that level of "we need to optimize this" currently so you can just throw tokens at the problem.
    - 6mo ago
stackghost 6mo ago
I was doing TryHackMe's "advent of cyber" sidequest last christmas and used a process very much like Carlini's that is outlined in TFA. >I'm doing a CTF. I popped a shell on this box and found this binary. Here is a ghidra decompilation. Is there anything exploitable in $function? You can't just ask Claude or ChatGPT to do the binex for you, but even last year's models were really good at finding heap or stack vulns this way.
thadt 6mo ago
So the intersting question: are we long term safer with "simpler" closer to hardware memory unsafe(ish) environments like Zig, or is the memory safe but more abstract feature set of languages like Rust still the winning direction? If a hypothetical build step is "look over this program and carfully examine the bounds of safety using your deep knowledge of the OS, hardware, language and all the tools that come along with it", then a less abstract environment might be at an overall advantage. In a moment, I'll close this comment and go back to writing Rust. But if I had the time (or tooling) to build something in C and test it as thoroughly as say, SQLite [1], then I might think harder about the tradeoffs. [1] https://sqlite.org/whyc.html https://sqlite.org/whyc.html
- deleted 6mo ago
  [deleted]
- love2read 6mo ago
  What about this article raises this question? If anything, this article makes it pretty clear that memory safe languages are a win. It seems like a serious disadvantage to require a nondeterministic program to evaluate your code's safety.
  - thadt 6mo ago
    In general I agree and suspect that memory safety is a tool that will continue to pay dividends for some time. But there are tradeoffs and more ways to write correct and 'safe' code than doing it in a "memory safe" language. If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs). The rub has been that writing full coverage tests, fuzzing, auditing, etc. has been costly. If those costs have changed, then it's an interesting topic to try to undertand how.
    - lmm 6mo ago
      > If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs). More like: a few people have been able to write C code where the vulnerabilities are obscure enough that we mostly don't discover them very often. The result of the phenomenon described in the article is that the gap between 99.9% secure and 100% secure just got a whole lot wider. Using herculean amounts of testing and fuzzing to catch most of the holes in a language that lacks secure-by-construction qualities is going to be even less viable going forward.
tonymet 6mo ago
I agree AI makes exploits more accessible, it also makes pen-testing and finding vulns more accessible, in both early and late stages of product development. AI has saved me a ton of money and time auditing. Mostly because I'm tired / lazy. It's both a black pill & white pill, and if we have the right discipline, a tremendous white pill. Engineers can no longer claim to be "cost effective" by ignoring vulns.
rkrbaccord94f 6mo ago
The pipewire-libs package local address function refers to alsa_output.pci Driver benchmarking the pipewire script calls three local ports: local.source.port = 10001 local.repair.port = 10002 local.control.port = 10003
samuelknight 6mo ago
LLMs are expert hackers because: 1) They are expert coders, including a decently comprehensive CVE knowledge 2) They know every programming language/framework/stack 3) They know every human language They already have super human breadth and attention. And their depth is either super human or getting there. The state of the security industry through 2025 was expensive appsec human reviewers or primitive scanners. Now you can spend a few dollars and have an expert intelligence scrutinize a whole network.
- gdulli 6mo ago
  So much of the current internet is posts that read as a superposition of sincere and parody, and until that's resolved how do you know how to respond?
  - saltcured 6mo ago
    Just wait until you see the same showing up in compliance realms... Edit: to be slightly less implicit, consider the cargo cult madness that erupts from people thinking they can address risk management and compliance by auto-generating documentation and avoid really doing the legwork.
  - samuelknight 6mo ago
    If that was a jab it my writing then yes, I am absolutely being sincere because I am an expert on this topic. LLMs went from being ok at one-shoting a function a to being so good at hacking that it's difficult to evaluate them. Prospective customers get back to us after a demo and tell us about the exploits it found on their services that are so vague and technical that they wouldn't think to look for them.
    - streetfighter64 6mo ago
      > Prospective customers get back to us after a demo and tell us about the exploits it found on their services that are so vague and technical that they wouldn't think to look for them. Um, have you actually verified that those are actual exploits then? Vague and technical sounds exactly like a description of AI slop...
vibe42 6mo ago
If everyone is running the same models, does this not favour white hat / defense? Since many exploits consists of several vulnerabilities used in a chain, if a LLM finds one in the middle and it's fixed, that can change a zero day to something of more moderate severity? E.g. someone finds a zero day that's using three vulns through different layers. The first and third are super hard to find, but the second is of moderate difficulty. Automated checks by not even SOTA models could very well find the moderate difficulty vuln in the middle, breaking the chain.
- dumpsterdiver 6mo ago
  > If everyone is running the same models, does this not favour white hat / defense? The landscape is turbulent (so this comment might be outdated by the time I submit it), but one thing I’m catching between the lines is a resistance to provide defensive coding patterns because (guessing) they make the flaw they’re defending against obvious. When the flaw is widespread - those patterns effectively make it cheap to attack for observant eyes. After seeing the enhanced capabilities recently, my conspiracy theory is that models do indeed traverse the pathways containing ideal mitigations, but they fall back to common anti-patterns when they hit the guardrails. Some of the things I’ve seen are baffling, and registered as adversarial on my radar.
anematode 6mo ago
Ya, I tend to believe that (most) human VR will be obsoleted well before human software engineering. Software engineering is a lot more squishy and has many more opportunities to go off the rails. Once a goal is established, the output of VR agents is verifiable.
GTP 6mo ago
> The new models find real stuff. Forget the slop; will projects be able to keep up with a steady feed of verified, reproducible, reliably-exploitable sev:hi vulnerabilities? If LLMs are as capable as said in the article, there will be an initial wave of security vulnerabilities. But then, all vulnerabilities will be discovered (or at least, LLMs will not find any more), and only new code will introduce new vulnerabilities. And everyone will be using LLMs to check the new code. So, regardless of what they say is correct or not, the problem doesn't really exist.
m132 6mo ago
A hard read for a skeptic like me. A lot of speculation and extrapolation of a trend, not to say outright exaggeration, but very little actual data. Let's not forget that we're at the tip of an economic bubble, and what you're writing about is at the very center of it! For what it's worth, I read Anthropic's write-up of their recent 0-day hunt that most of this post seems to be based on, and I can't help but notice that (assuming the documented cases were the most "spectacular") their current models mostly "pattern-matched" their ways towards the exploits; in all documented cases, the actual code analysis failed and the agents redeemed themselves by looking for known-vulnerable patterns they extracted from the change history or common language pitfalls. So, most of the findings, if not all, were results of rescanning the entire codebase for prior art. The corporate approach to security, just a little more automated. Hence I agree with "the smartest vulnerability researcher" mentioned near the end. Yes, the most impactful vulnerabilities tend to be the boring ones, and catching those fast will make a big difference, but vulnerability research is far from cooked. If anything, it will get much more interesting.
- acdha 6mo ago
  I tend to be skeptical but listening to the linked podcast with Carlini and found him very credible–not a sales guy, not an AI doomer, but someone talking about how little work he had to do to find real exploits in heavily-fuzzed code. I think there’s still a safe bet that many apps will be cumbersome to attack but I think it’s still going to happen faster than I used to think. https://securitycryptographywhatever.com/2026/03/25/ai-bug-finding/ https://securitycryptographywhatever.com/2026/03/25/ai-bug-f...
  - tptacek 6mo ago
    Nicholas Carlini is the real deal. He was most recently on the front page for "How to win a best paper award", about his experience winning a series of awards at Big 4 academic security conferences, mostly recently for work he coauthored with Adi Shamir (I'm just namedropping the obvious name) on stealing the weights from deep neural networks. Before all that (and before he got his doctorate), he and Hans Nielsen wrote the back half of Microcorruption. He's not a sales guy.
miki123211 6mo ago
I think our saving grace is the fact that, especially in these hardened environments, it's a lot easier to find exploitable bugs than to actually exploit them. As the defenders will have access to the same agents as the attackers, everybody will (mostly) find the same bugs. If recent trends continue[1], it's likely that major labs will make new models available to defenders first, making the attackers' jobs even harder. What really worries me is models quickly developing exploits based on freshly-released patches, before most people had a chance to update. Big cloud vendors will likely have the ability to coordinate and deploy updates before the commits hit Github, smaller enterprise on-prem environments won't have that luxury.
jazz9k 6mo ago
The token cost will be a limiting factor.
- tptacek 6mo ago
  Will it? Why do you assume that?
somesortofthing 6mo ago
Am I wrong in thinking that an "exploits are free" environment massively favors the defender? Given that real-world exploits usually chain 0days, the attacker has to find the whole chain while the defender only needs to fix the weakest link. The defender also gets to make the first move by just putting a "run an agent to find vulns" step in their CI pipeline. If LLMs truly make finding exploits free, almost no LLM-findable exploits will ever make it into the codebase. The only way break the equilibrium is still going to be a smart researcher capable of finding exploits that the commoditized tools alone can't.
- ActorNightly 6mo ago
  You aren't wrong for the most part, but this whole thing of "find me vulns" is not really accurately describing the space. Finding vulns has almost become sort of like a vibe thing even before LLMs. There would be some security patch that everyone says is critical because it fixes a vulnerability, but the vulnerability is like "under certain conditions, and given physical access to the device, an attacker can craft a special input that crashes the service"... and thats it. Even stuff like Spectre and Meltdown, which I highly doubt an LLM can find on its own without specifically knowing about speculative execution attacks, are incredibly hard to use. People made a big deal of those being able to be used from javascript, but to actually leak anything of importance you need to know memory layouts, a bunch of other info and so on. So while an LLM can patch all the up front vulnerabilities, most if not all of those are completely useless to an attacker. Modern systems are incredibly secure. On the flip side, the stuff that LLM doesn't know about, that can be exploited. For example, assume that log4shell hasn't been found yet, and that log statements by default can pull jni objects from the internet and execute them. The llms would happily write you code with log statements using log4j, and pass it through vulnerability checker, and I would bet that even at the bytecode level it won't ever figure out that vulnerability exists. And overall, because of Rice theorem, you can't tell if the program is fully exploitable or not without actually running it in some form and way. LLMS can help you with this (but not fully of course) by actually running it and fuzzing inputs and observing memory traces, but even this gets very hard when you introduce things like threading and timed executions which can all affect the result. And also, the LLMs themselves are an exploit vector now. If you manage to intercept the API calls somehow and insert code or other instruction, you can have the developer essentially put the exploit for you into the code. So I would say the field is about even.
DeathArrow 6mo ago
If this is true, beside state actors who did this from the beginning, there is probably a race between criminal organizations to develop hacking tools and frameworks to efficiently extract and exploit as much data as possible.
themafia 6mo ago
> I think this outcome is locked in. That we’re starting to see its first clear indications. Hardly. The linked anthropic paper is extremely underwhelming. It portrays no tectonic shifts. > Practitioners will suffer having to learn the anatomy of the font gland or the Unicode text shaping lobe or whatever other “weird machines” are au courant That's absurd. Do the vulnerability writers _start_ with this knowledge? Of course they don't. They work backwards. Anyone can do this. It just takes time in a category of development that most open source authors don't like to be occupied by. > You can’t design a better problem for an LLM agent than exploitation research. Did you read the anthropic article you linked? It found absolutely nothing and then immediately devolved into a search for 'strcat.' That's it. Again, literally _anyone with the time_ could just do this. > a frontier LLM already encodes supernatural amounts of correlation across vast bodies of source code. 'grep strcat' is "supernatural?" This starts sprawling very quickly after this. The AI revolution is not real. The cargo cult is headed for a new winter. I only see articles proclaiming the sky is just about to fall any day now, yet, I see no real world evidence any such thing is happening or likely to happen.
motbus3 6mo ago
As many are saying in the comments... I understand the point of view but if this is all true, why so many open source projects are giving up because of the staggering amount of fake/useless reports. This is the situation where a software will be pre-patched until bloated for no particular reason... I still think this will happen, but the eventual findings of real security issues at the moment is not really proof it works. A 1/50 real Vs. false is not acceptable even if the plan is to solve with llms.
deleted 6mo ago
[deleted]
deleted 6mo ago
[deleted]
siruwastaken 6mo ago
I can't fully agree with the author's worries about the legislation question. Even if legislation were to forbid using LLMs for vulnerability reports at first, they would quickly learn their lesson and reverse the policies. Not even a politician can fight against real world results.
abc123abc123 6mo ago
'Substantial amounts of high-impact vulnerability research (maybe even most of it) will happen simply by pointing an agent at a source tree and typing “find me zero days”' Not quite... what is forgotten here is that the developers themselves, with equal ease, _also_ will point agents at the source tree and will type "find me zero days".
HackerThemAll 6mo ago
If we can't get zero-days discovered and fixed in due time to protect our privacy, I certainly do hope one day AI will discover most of it and suggest how to fix it. I do hope it's going to be capable enough to be plugged into CI/CD to discover that the top-talent today made another obvious XSS, SQLi or other trivial issue that just created a 0-day. Even a few of those cyber-models, so they verify each other. I do hope it's going to be trained on all prior issues, like the one with xz, or Axios, and be vigilant against these things.

267 points by pedro84 6mo ago

deleted 6mo ago

[deleted]

ronnier 6mo ago

[dead]

nitros 6mo ago

I'm suspicious of this prediction given the curl project's experiences...

tptacek 6mo ago
Everybody agrees that idiots were spamming curl with random just-plausible-enough-seeming output from old models.
- tomjakubowski 6mo ago
  It sounds like what makes the pipeline in the article effective is the second stage, which takes in the vulnerability reports produced by the first level and confirms or rejects them. The article doesn't say what the rejection rate is there. I don't think the spammers would think to write the second layer, they would most likely pipe the first layer (a more naive version of it too, probably) directly to the issue feed.
  - tptacek 6mo ago
    There are at least three differences: * Carlini's team used new frontier models that have gotten materially better at finding vulnerabilities (talk to vulnerability researchers outside the frontier labs, they'll echo that). Stenberg was getting random slop from people using random models. * Carlini's process is iterated exhaustively over the whole codebase; he's not starting with a repo and just saying "find me an awesome bug" and taking that and only that forward in the process. * And then yes, Carlini is qualifying the first-pass findings with a second pass.
    - tomjakubowski 6mo ago
      Thanks, I hadn't considered the second point. I guess the broader point I wanted to make is about the people responsible for the deluge of LLM-reported bugs and security vulnerabilities on countless open-source projects (not only on curl): they weren't considerate or thoughtful security researchers, they were spammers looking to raise their profile with fully automated, hands-off open source "contributions". I would expect that the spammers would continue to use whatever lowest common denominator tooling is available, and continue to cause these headaches for maintainers. That doesn't mean frontier models and tooling built around them aren't genuinely useful to people doing serious security research: that does seem to be the case, and I'm glad for it.
wslh 6mo ago
The problem is that you have all kind of "security spam" in the same way that social media is flooded by automatic, but on-topic, content. This doesn't mean that some very few reports are not correct. One way to filter that out could be to receive the PoC of the exploit, and test it in some sandbox. I think what XBOW and others are doing is real.
jerf 6mo ago
The people spamming curl did step one, "write me a vulnerability report on X" but skipped step two, "verify for me that it's actually exploitable". Tack on a step three where a reasonably educated user in the field of security research does a sanity check on the vulnerability implementation as well and you'll have a pipeline that doesn't generate a ton of false positives. The question then will rather be how cost-effective it is for the tokens and the still-non-zero human time involved.
MajesticHobo2 6mo ago
That was then, this is now. The new models are scarily good. If you're skeptical, just take an hour to replicate the strategy the article references. Point Claude at any open-source codebase you find interesting and instruct it to find exploitable vulnerabilities. Give it a well-defined endpoint if you want (e.g., "You must develop a Python script that triggers memory corruption via a crafted request") and see how well it does.
- phyzome 6mo ago
  > That was then, this is now. No, what we were seeing with curl was script kiddies. It wasn't about the quality of the models at all. They were not filtering their results for validity.
  - MajesticHobo2 6mo ago
    It was definitely partially about model quality. The frontier models are capable of producing valid findings with (reasonably) complex exploit chains on the first pass (or with limited nudging) and are much less prone to making up the kinds of nonsensical reports that were submitted to curl. Compared to now, the old models essentially didn't work for security. If those script kiddies had been using today's models instead and _still_ didn't do any filtering, a lot more of those bugs would have been true positives.
gsnedders 6mo ago
To some extent, that’s just the nature of the incentive structure — you pay money for exploits with no penalty for false reports? Just rely on monkeys typing reports till one happens to be correct.

tomjakubowski 6mo ago

> Now consider the poor open source developers who, for the last 18 months, have complained about a torrent of slop vulnerability reports. I’d had mixed sympathies, but the complaints were at least empirically correct. That could change real fast. The new models find real stuff. The slop reports won't stop just because real ones are coming in. If the author's right, open source maintainers will still will have to deal with the torrent of slop: on top of triaging and identifying the legit vulnerabilities. Obviously, this is just another role for AI models to fill.

badgersnake 6mo ago

Another boring AI hype article. “The next model will be the one. Trust me. Just one more iteration.”

deleted 6mo ago
[deleted]

stavros 6mo ago

I don't understand why the takeaway here is (unless I'm missing something), more or less "everything is going to get exploited all the time". If LLMs can really find a ton of vulnerabilities in my software, why would I not run them and just patch all the vulnerabilities, leading to perfectly secure software (or, at the very least, software for which LLMs can no longer find any new vulnerabilities)?

tptacek 6mo ago
That might be one outcome, especially for large, expertly-staffed vendors who are already on top of this stuff. My real interest in what happens to the field for vulnerability researchers.
- stavros 6mo ago
  True, but I already am curious to see what happens in a multitude of fields, so this is just one more entry in that list.
- lifty 6mo ago
  Perhaps a meta evolution, they become experts at writing harnesses and prompts for discovering and patching vulnerabilities in existing code and software. My main interest is, now that we have LLMs, will the software industry move to adopting techniques like formal verification and other perhaps more lax approaches that massively increase the quality of software.
  - habinero 6mo ago
    Testing exists. > formal verification Outside of limited specific circumstances, formal verification gives you nothing that tests don't give you, and it makes development slow and iteration a chore. People know about it, and it's not used for lot of reasons.
    - threethirtytwo 6mo ago
      This statement shows an intense lack of technical knowledge. You’re probably one of those ignorant managerial types. First type checking is a form of formal verification and it’s used everywhere. Second have you heard of rust? Do you know why it’s becoming an alternative to C++ or C? Entirely because of its type checker or aka formal verification. It is the literal main reason why rust was created. Have you heard of typescript? It’s essentially a formal verification layer over JavaScript. Everyone uses it now for the front end. You don’t know what you’re talking about. I recommend you do some research before saying anything on this site.

spr-alex 6mo ago

I interned for the author at 18. I assumed security testing worked like this: 1. Static analysis catches nearly all bugs with near-total code coverage 2. Private tooling extends that coverage further with better static analysis and dynamic analysis, and that edge is what makes contractors valuable 3. Humans focus on design flaws and weird hardware bugs like cryptographic side-channels from electromagnetic emanations Turns out finding all the bugs is really hard. Codebases and compiler output have exploded in complexity over 20 years which has not helped the static analysis vision. Todays mitigations are fantastic compared to then, but just this month a second 0day chain got patched on one of the best platforms for hardware mitigations. I think LLMs get us meaningfully closer to what I thought this work already was when I was 18 and didn't know anything.

cartoonworld 6mo ago
lots of security issues form at the boundaries between packages, zones, services, sessions, etc. Static analysis could but doesn't seem to catch this stuff from my perspective. Bugs are often chains and that requires a lot of creativity, planning etc consider logic errors and race conditions. Its surely not impossible for llm to find these, but it seems likely that you'll need to step throught the program control flow in order to reveal a lot of these interactions. I feel like people consider LLM as free since there isn't as much hand-on-keyboard. I kinda disgree, and when the cost of paying out these vulns falls, I feel like nobody is gonna wanna eat the token spend. Plenty of hackers already use ai in their workflows, even then it is a LOT OF WORK.
Legend2440 6mo ago
Catching all bugs with static analysis would involve solving the halting problem, so it's never going to happen.
- MeetingsBrowser 6mo ago
  Catching all bugs with static analysis is actually really easy, as long as you don't mind false positives.

deleted 6mo ago

[deleted]

streetfighter64 6mo ago

> Is the Linux KVM hypervisor connected to the hrtimer subsystem, workqueue, or perf_event? The model knows. I asked ChatGPT and it claimed "all three". Any linux wizards who can confirm or deny? Anyway, in my experience using mainly the Claude chat to do some basic (not security) bug hunting, it usually fixates on one specific hypothesis, and it takes some effort to get it off that wrong track, even when I already know it's barking up the wrong tree.

tptacek 6mo ago
It's all three, I just had it on the brain when I was writing this.
- streetfighter64 6mo ago
  Hm, kind of a strange question then, no? Is a car's engine connected to the fuel tank, the wheels or the accelerator pedal?
  - tptacek 6mo ago
    I don't know, maybe it is? My point is just that frontier models start off with latent models of all the interconnectivity in all the important open-source codebases, to a degree that would be infeasible for the people who learned how all the CSS object lifecycles and image rendering and unicode shaping stuff worked well enough to use them in exploits.
jgeralnik 6mo ago
The wonderful thing though is that you can just run the model multiple times (even in parallel). Some instances might get stuck but as long as some find the bug and you have a good way to filter outputs (e.g. with another llm that tries to create concrete exploits) even a very small success rate on stage 1 can lead to reliable exploits

staticassertion 6mo ago

> Everything is up in the air. The industry is sold on memory-safe software, but the shift is slow going. We’ve bought time with sandboxing and attack surface restriction. How well will these countermeasures hold up? A 4 layer system of sandboxes, kernels, hypervisors, and IPC schemes are, to an agent, an iterated version of the same problem. Agents will generate full-chain exploits, and they will do so soon. I think this is the interesting bit. We have some insanely powerful isolation technology and mitigations. I can put a webassembly program into a seccomp'd wrapper in an unprivileged user into a stripped down Linux environment inside of Firecracker. An attacker breaking out of that feels like science fiction to me. An LLM could do it but I think "one shots" for this sort of attack are extremely unlikely today. The LLM will need to find a wasm escape, then a Linux LPE that's reachable from an unprivileged user with a seccomp filter, then once they have kernel control they'll need to manipulate the VM state or attack KVM directly. A human being doing those things is hard to imagine. Exploitation of Firecracker is, from my view, extremely difficult. The bug density is very low - code quality is high and mitigation adoption is a serious hurdle. Obviously people aren't just going to deploy software the way I'm suggesting, but even just "I use AWS Fargate" is a crazy barrier that I'm skeptical an LLM will cross. > Meanwhile, no defense looks flimsier now than closed source code. Interesting, I've had sort of the opposite view. Giving an LLM direct access to the semantic information of your program, the comments, etc, feels like it's just handing massive amounts of context over. With decompilation I think there's a higher risk of it missing the intention of the code. edit: I want to also note that with LLMs I have been able to do sort of insane things. A little side project I have uses iframe sandboxing insanely aggressively. Most of my 3rd party dependencies are injected into an iframe, and the content is rendered in that iframe. It can communicate to the parent over a restricted MessageChannel. For cases like "render markdown" I can even leverage a total-blocking CSP within the sandbox. Writing this by hand would be silly, I can't do it - it's like building an RPC for every library I use. "Resize the window" or "User clicked this link" etc all have to be written individually. But with an LLM I'm getting sort of silly levels of safety here - Chrome is free to move each iframe into its own process, I get isolated origins, I'm immune from supply chain vulnerabilities, I'm immune to mostly immune to XSS (within the frame, where most of the opportunity is) and CSRF is radically harder, etc. LLMs have made adoption of Trusted Types and other mitigations insanely easy for me and, IMO, these sorts of mitigations are more effective at preventing attacks than LLMs will be at finding bypasses (contentious and platform dependent though!). I suppose this doesn't have any bearing on the direct position of the blog post, which is scoped to the new role for vulnerability research, but I guess my interest is obviously going to be more defense oriented as that's where I live :)

rubiquity 6mo ago

I was distracted by the picture of the ingredients to a Final Ward being at the top of the page.

narginal 6mo ago

Just like how fuzzers will find all the bugs, right? Right?? There's definitely infrastructure at these big companies that isn't sitting in a while loop 'fuzzing' right? Why is it news that vulnerability research will continue to get harder, exactly? It has always been this way, exploits will get more expensive, and the best researchers will continue with whatever tools they find useful.

tptacek 6mo ago
It's a good question. Fuzzers generated a surge of new vulnerabilities, especially after institutional fuzzing clusters got stood up, and after we converged on coverage-guided fuzzers like AFL. We then got to a stable equilibrium, a new floor, such that vulnerability research & discovery doesn't look that drastically different after fuzzing as before. Two things to notice: * First, fuzzers also generated and continue to generate large stacks of unverified crashers, such that you can go to archives of syzkaller crashes and find crashers that actually work. My contention is that models are not just going to produce hypothetical vulnerabilities, but also working exploits. * Second, the mechanism 4.6 and Codex are using to find these vulnerabilities is nothing like that of a fuzzer. A fuzzer doesn't "know" it's found a vulnerability; it's a simple stimulus/response test (sequence goes in, crash does/doesn't come out). Most crashers aren't exploitable. Models can use fuzzers to find stuff, and I'm surprised that (at least for Anthropic's Red Team) that's not how they're doing it yet. But at least as I understand it, that's generally not what they're doing. It something much closer to static analysis.
- staticassertion 6mo ago
  I suspect we'll see combinations of symbolic execution + fuzzing as contextual inputs to LLMs, with LLMs delegating highly directed tasks to these external tools that are radically faster at exploring a space with the LLM guiding based on its own semantic understanding of the code. I'm with you, I expected this to be happening already. Funny enough, I guess even a hardened codebase isn't at that level of "we need to optimize this" currently so you can just throw tokens at the problem.
  - 6mo ago

stackghost 6mo ago

I was doing TryHackMe's "advent of cyber" sidequest last christmas and used a process very much like Carlini's that is outlined in TFA. >I'm doing a CTF. I popped a shell on this box and found this binary. Here is a ghidra decompilation. Is there anything exploitable in $function? You can't just ask Claude or ChatGPT to do the binex for you, but even last year's models were really good at finding heap or stack vulns this way.

thadt 6mo ago

So the intersting question: are we long term safer with "simpler" closer to hardware memory unsafe(ish) environments like Zig, or is the memory safe but more abstract feature set of languages like Rust still the winning direction? If a hypothetical build step is "look over this program and carfully examine the bounds of safety using your deep knowledge of the OS, hardware, language and all the tools that come along with it", then a less abstract environment might be at an overall advantage. In a moment, I'll close this comment and go back to writing Rust. But if I had the time (or tooling) to build something in C and test it as thoroughly as say, SQLite [1], then I might think harder about the tradeoffs. [1] https://sqlite.org/whyc.html https://sqlite.org/whyc.html

deleted 6mo ago
[deleted]
love2read 6mo ago
What about this article raises this question? If anything, this article makes it pretty clear that memory safe languages are a win. It seems like a serious disadvantage to require a nondeterministic program to evaluate your code's safety.
- thadt 6mo ago
  In general I agree and suspect that memory safety is a tool that will continue to pay dividends for some time. But there are tradeoffs and more ways to write correct and 'safe' code than doing it in a "memory safe" language. If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs). The rub has been that writing full coverage tests, fuzzing, auditing, etc. has been costly. If those costs have changed, then it's an interesting topic to try to undertand how.
  - lmm 6mo ago
    > If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs). More like: a few people have been able to write C code where the vulnerabilities are obscure enough that we mostly don't discover them very often. The result of the phenomenon described in the article is that the gap between 99.9% secure and 100% secure just got a whole lot wider. Using herculean amounts of testing and fuzzing to catch most of the holes in a language that lacks secure-by-construction qualities is going to be even less viable going forward.

tonymet 6mo ago

I agree AI makes exploits more accessible, it also makes pen-testing and finding vulns more accessible, in both early and late stages of product development. AI has saved me a ton of money and time auditing. Mostly because I'm tired / lazy. It's both a black pill & white pill, and if we have the right discipline, a tremendous white pill. Engineers can no longer claim to be "cost effective" by ignoring vulns.

rkrbaccord94f 6mo ago

The pipewire-libs package local address function refers to alsa_output.pci Driver benchmarking the pipewire script calls three local ports: local.source.port = 10001 local.repair.port = 10002 local.control.port = 10003

samuelknight 6mo ago

LLMs are expert hackers because: 1) They are expert coders, including a decently comprehensive CVE knowledge 2) They know every programming language/framework/stack 3) They know every human language They already have super human breadth and attention. And their depth is either super human or getting there. The state of the security industry through 2025 was expensive appsec human reviewers or primitive scanners. Now you can spend a few dollars and have an expert intelligence scrutinize a whole network.

gdulli 6mo ago
So much of the current internet is posts that read as a superposition of sincere and parody, and until that's resolved how do you know how to respond?
- saltcured 6mo ago
  Just wait until you see the same showing up in compliance realms... Edit: to be slightly less implicit, consider the cargo cult madness that erupts from people thinking they can address risk management and compliance by auto-generating documentation and avoid really doing the legwork.
- samuelknight 6mo ago
  If that was a jab it my writing then yes, I am absolutely being sincere because I am an expert on this topic. LLMs went from being ok at one-shoting a function a to being so good at hacking that it's difficult to evaluate them. Prospective customers get back to us after a demo and tell us about the exploits it found on their services that are so vague and technical that they wouldn't think to look for them.
  - streetfighter64 6mo ago
    > Prospective customers get back to us after a demo and tell us about the exploits it found on their services that are so vague and technical that they wouldn't think to look for them. Um, have you actually verified that those are actual exploits then? Vague and technical sounds exactly like a description of AI slop...

vibe42 6mo ago

If everyone is running the same models, does this not favour white hat / defense? Since many exploits consists of several vulnerabilities used in a chain, if a LLM finds one in the middle and it's fixed, that can change a zero day to something of more moderate severity? E.g. someone finds a zero day that's using three vulns through different layers. The first and third are super hard to find, but the second is of moderate difficulty. Automated checks by not even SOTA models could very well find the moderate difficulty vuln in the middle, breaking the chain.

dumpsterdiver 6mo ago
> If everyone is running the same models, does this not favour white hat / defense? The landscape is turbulent (so this comment might be outdated by the time I submit it), but one thing I’m catching between the lines is a resistance to provide defensive coding patterns because (guessing) they make the flaw they’re defending against obvious. When the flaw is widespread - those patterns effectively make it cheap to attack for observant eyes. After seeing the enhanced capabilities recently, my conspiracy theory is that models do indeed traverse the pathways containing ideal mitigations, but they fall back to common anti-patterns when they hit the guardrails. Some of the things I’ve seen are baffling, and registered as adversarial on my radar.

anematode 6mo ago

Ya, I tend to believe that (most) human VR will be obsoleted well before human software engineering. Software engineering is a lot more squishy and has many more opportunities to go off the rails. Once a goal is established, the output of VR agents is verifiable.

GTP 6mo ago

> The new models find real stuff. Forget the slop; will projects be able to keep up with a steady feed of verified, reproducible, reliably-exploitable sev:hi vulnerabilities? If LLMs are as capable as said in the article, there will be an initial wave of security vulnerabilities. But then, all vulnerabilities will be discovered (or at least, LLMs will not find any more), and only new code will introduce new vulnerabilities. And everyone will be using LLMs to check the new code. So, regardless of what they say is correct or not, the problem doesn't really exist.

m132 6mo ago

A hard read for a skeptic like me. A lot of speculation and extrapolation of a trend, not to say outright exaggeration, but very little actual data. Let's not forget that we're at the tip of an economic bubble, and what you're writing about is at the very center of it! For what it's worth, I read Anthropic's write-up of their recent 0-day hunt that most of this post seems to be based on, and I can't help but notice that (assuming the documented cases were the most "spectacular") their current models mostly "pattern-matched" their ways towards the exploits; in all documented cases, the actual code analysis failed and the agents redeemed themselves by looking for known-vulnerable patterns they extracted from the change history or common language pitfalls. So, most of the findings, if not all, were results of rescanning the entire codebase for prior art. The corporate approach to security, just a little more automated. Hence I agree with "the smartest vulnerability researcher" mentioned near the end. Yes, the most impactful vulnerabilities tend to be the boring ones, and catching those fast will make a big difference, but vulnerability research is far from cooked. If anything, it will get much more interesting.

acdha 6mo ago
I tend to be skeptical but listening to the linked podcast with Carlini and found him very credible–not a sales guy, not an AI doomer, but someone talking about how little work he had to do to find real exploits in heavily-fuzzed code. I think there’s still a safe bet that many apps will be cumbersome to attack but I think it’s still going to happen faster than I used to think. https://securitycryptographywhatever.com/2026/03/25/ai-bug-finding/ https://securitycryptographywhatever.com/2026/03/25/ai-bug-f...
- tptacek 6mo ago
  Nicholas Carlini is the real deal. He was most recently on the front page for "How to win a best paper award", about his experience winning a series of awards at Big 4 academic security conferences, mostly recently for work he coauthored with Adi Shamir (I'm just namedropping the obvious name) on stealing the weights from deep neural networks. Before all that (and before he got his doctorate), he and Hans Nielsen wrote the back half of Microcorruption. He's not a sales guy.

miki123211 6mo ago

I think our saving grace is the fact that, especially in these hardened environments, it's a lot easier to find exploitable bugs than to actually exploit them. As the defenders will have access to the same agents as the attackers, everybody will (mostly) find the same bugs. If recent trends continue[1], it's likely that major labs will make new models available to defenders first, making the attackers' jobs even harder. What really worries me is models quickly developing exploits based on freshly-released patches, before most people had a chance to update. Big cloud vendors will likely have the ability to coordinate and deploy updates before the commits hit Github, smaller enterprise on-prem environments won't have that luxury.

jazz9k 6mo ago

The token cost will be a limiting factor.

tptacek 6mo ago
Will it? Why do you assume that?

somesortofthing 6mo ago

Am I wrong in thinking that an "exploits are free" environment massively favors the defender? Given that real-world exploits usually chain 0days, the attacker has to find the whole chain while the defender only needs to fix the weakest link. The defender also gets to make the first move by just putting a "run an agent to find vulns" step in their CI pipeline. If LLMs truly make finding exploits free, almost no LLM-findable exploits will ever make it into the codebase. The only way break the equilibrium is still going to be a smart researcher capable of finding exploits that the commoditized tools alone can't.

ActorNightly 6mo ago
You aren't wrong for the most part, but this whole thing of "find me vulns" is not really accurately describing the space. Finding vulns has almost become sort of like a vibe thing even before LLMs. There would be some security patch that everyone says is critical because it fixes a vulnerability, but the vulnerability is like "under certain conditions, and given physical access to the device, an attacker can craft a special input that crashes the service"... and thats it. Even stuff like Spectre and Meltdown, which I highly doubt an LLM can find on its own without specifically knowing about speculative execution attacks, are incredibly hard to use. People made a big deal of those being able to be used from javascript, but to actually leak anything of importance you need to know memory layouts, a bunch of other info and so on. So while an LLM can patch all the up front vulnerabilities, most if not all of those are completely useless to an attacker. Modern systems are incredibly secure. On the flip side, the stuff that LLM doesn't know about, that can be exploited. For example, assume that log4shell hasn't been found yet, and that log statements by default can pull jni objects from the internet and execute them. The llms would happily write you code with log statements using log4j, and pass it through vulnerability checker, and I would bet that even at the bytecode level it won't ever figure out that vulnerability exists. And overall, because of Rice theorem, you can't tell if the program is fully exploitable or not without actually running it in some form and way. LLMS can help you with this (but not fully of course) by actually running it and fuzzing inputs and observing memory traces, but even this gets very hard when you introduce things like threading and timed executions which can all affect the result. And also, the LLMs themselves are an exploit vector now. If you manage to intercept the API calls somehow and insert code or other instruction, you can have the developer essentially put the exploit for you into the code. So I would say the field is about even.

DeathArrow 6mo ago

If this is true, beside state actors who did this from the beginning, there is probably a race between criminal organizations to develop hacking tools and frameworks to efficiently extract and exploit as much data as possible.

themafia 6mo ago

> I think this outcome is locked in. That we’re starting to see its first clear indications. Hardly. The linked anthropic paper is extremely underwhelming. It portrays no tectonic shifts. > Practitioners will suffer having to learn the anatomy of the font gland or the Unicode text shaping lobe or whatever other “weird machines” are au courant That's absurd. Do the vulnerability writers _start_ with this knowledge? Of course they don't. They work backwards. Anyone can do this. It just takes time in a category of development that most open source authors don't like to be occupied by. > You can’t design a better problem for an LLM agent than exploitation research. Did you read the anthropic article you linked? It found absolutely nothing and then immediately devolved into a search for 'strcat.' That's it. Again, literally _anyone with the time_ could just do this. > a frontier LLM already encodes supernatural amounts of correlation across vast bodies of source code. 'grep strcat' is "supernatural?" This starts sprawling very quickly after this. The AI revolution is not real. The cargo cult is headed for a new winter. I only see articles proclaiming the sky is just about to fall any day now, yet, I see no real world evidence any such thing is happening or likely to happen.

motbus3 6mo ago

As many are saying in the comments... I understand the point of view but if this is all true, why so many open source projects are giving up because of the staggering amount of fake/useless reports. This is the situation where a software will be pre-patched until bloated for no particular reason... I still think this will happen, but the eventual findings of real security issues at the moment is not really proof it works. A 1/50 real Vs. false is not acceptable even if the plan is to solve with llms.

deleted 6mo ago

[deleted]

deleted 6mo ago

[deleted]

siruwastaken 6mo ago

I can't fully agree with the author's worries about the legislation question. Even if legislation were to forbid using LLMs for vulnerability reports at first, they would quickly learn their lesson and reverse the policies. Not even a politician can fight against real world results.

abc123abc123 6mo ago

'Substantial amounts of high-impact vulnerability research (maybe even most of it) will happen simply by pointing an agent at a source tree and typing “find me zero days”' Not quite... what is forgotten here is that the developers themselves, with equal ease, _also_ will point agents at the source tree and will type "find me zero days".

HackerThemAll 6mo ago

If we can't get zero-days discovered and fixed in due time to protect our privacy, I certainly do hope one day AI will discover most of it and suggest how to fix it. I do hope it's going to be capable enough to be plugged into CI/CD to discover that the top-talent today made another obvious XSS, SQLi or other trivial issue that just created a 0-day. Even a few of those cyber-models, so they verify each other. I do hope it's going to be trained on all prior issues, like the one with xz, or Axios, and be vigilant against these things.