4 ms·

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of the sort in the linked article or noise of the sort that is not exploitable.

bluGill 1mo ago
The majority these days seems to be real issues, but probably not exploitable. The latest LLMs are very good at reading code and finding issues where the code is wrong. They are somewhat less good at finding exploits - both because finding exploits is harder than finding code that is clearly wrong (even if not exploitable), and also because the better ones are intentionally made to not create exploits (since they don't know if you are a good or bad - they assume bad. However if I was writing this response just one year ago I would instead be saying: the majority off LLM CVS are noise where the code is correct, and often they are writing up for code that doesn't even exist. Which is to say I suspect the repo in question was generated with a year-old LLM, since they act like that. The new ones [mostly?] are much better. Still, if a modern LLM points out something you should fix it. Even if we can't figure out how to exploit it today that doesn't mean we won't figure it out in the future.
- thayne 1mo ago
  > I suspect the repo in question was generated with a year-old LLM I suspect there are a lot of people running inexpensive models that are searching for vulnerabilities across a lot of projects, probably in an automated way (ex with openclaw or similar) in the hopes of winning a bounty and/or noteriety.
  - bluGill 1mo ago
    Most bounty programs are aware of this. Many projects have closed their bounty program in response to that type of attack.
cogman10 1mo ago
This is what I truly don't like about the CVE system. One such example is CVE-2023-45853 [1]. Zlib included in it's source an extra set of utilities and add-ons. One such utility, MiniZip, had a buffer overflow vulnerability. BAM, 8.8 CVE (was a 9, looks like they pulled it back a bit). But not one that the 99% of applications using zlib would ever be vulnerable to because almost nobody used the MiniZip utility. It was so unused that the solution for zlib was to simply remove it. I know about this one particularly because our security policy required us to do a BUNCH of pointless updates for it since zlib is in just about everything. [1] https://app.opencve.io/cve/CVE-2023-45853 https://app.opencve.io/cve/CVE-2023-45853
- post-it 1mo ago
  But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
  - cogman10 1mo ago
    Well that's the thing, to build the utilities required extra flags which were pretty rarely enabled. You can, in most distros, ultimately install minizip as a separate package but few do. It's not that useful of a utility. Most people will likely just grab the full blown "zip" application https://infozip.sourceforge.net/Zip.html https://infozip.sourceforge.net/Zip.html . Though on linux, even more people are simply using tar with a zlib extension. That's the `tar.gz` files.
    - ddevnyc 1mo ago
      I think this presents a highly fascinating scenario: 1. A vulnerability that presents itself very rarely 2. If it presents itself, it is fatal to the organization So, few targets are affected, but the outsized effect means that the overall economic impact is not insignificant. How does one keep track of that? One method is to use a sort of "kirchhoff's law" approach, similar to google page rank. The electrical analogy would be: - the attacker has a high potential, let's say 1000V. that attacker is the root of a rose tree, going from top to bottom, branching out towards the bottom. - nodes impossible to exploit present edges with infinite resistance - nodes that can be exploited present finite resistance (perhaps very low) - once a node is exploited, its node branches out to other things that now become accessible and may or may not be exploited - real economic impact presents a connection to ground, measured as 1/($economic impact) ohms resistance Once you have a structure like that, you can measure the hypothetical current that would be flowing, and measure the severity of such exploits. Sometimes a single path through a complex system can blow up vital, important parts, and this could be one way to measure it in some sort of objective manner.
pbronez 1mo ago
I once had a customer threaten to reject a delivery over a CVE. I dug into it. The CVE was that an Ocaml PostgreSQL client didn’t implement an authentication feature. I convinced the customer to accept the delivery by pointing out that (1) our app had zero lines of ocaml and (2) the feature had been implemented in the ocaml driver since the CVE was issued.
jmull 1mo ago
Yes, the CVE system is broken. LLM-generated CVEs is making it even worse. I suppose all these fake issues and the many more that have absurdly elevated severities could be considered an attack on the system itself, stripping it of credibility.
- brabel 1mo ago
  That's the worst case scenario right there: so many fake reports that the real vulnerabilities can no longer be reported properly and fixed quickly. Assuming some LLMs really are capable of finding serious vulnerabilities (which in my experience is absolutely the case : just let a good model run on your security code base and see for yourself) that means that we can more easily find vulnerabilities, but it's much harder to report them and be taken seriously - so the incentive to exploit such vulnerabilities instead has become much, much higher.
  - pixl97 1mo ago
    Having your LLM look at the security really isn't a great option. Most users don't have unlimited budgets and can't dump the necessary time and funds needed to find these flaws. On top of that, ability to prompt about flaws makes all the difference in the world. If you know what you're doing you can get better results. Problem, very few people know what they are doing. Going back to the money/time problem, LLMs are not deterministic. Much like the day you forgot to drink coffee, running LLM systems against code can get different results where things are found or not found. That or two different things are found on two different runs (with the same code) because attention was stolen by the first issue it found. So yea, in the LLM age proof is in the exploit pudding. Who cares if you're taken seriously, if you dump out an exploit that works the seriousness is now on the defenders time and people will scramble to fix it. "But what about exploit embargos"... Well, you just found the exploit with an LLM, how many other nefarious groups do you think are already exploiting it? The age of sitting on problems is dead.
dspillett 1mo ago
> The vast majority of CVEs are not exploitable, basically noise. This is not true if you consider security-in-depth. Many of them are exploitable on their own but maybe not in combination with other issues that are as yet unknown or known but not patched everywhere. As a simple example a local privilege escalation issue that is not exploitable on a device that only I ever have access to, essentially becomes a remote root access flaw if you have untrusted or unreliable users (clients with accounts for instance) on the system. This works on a finer grain too, seemingly minor issues spread through the kernel and user space can add up to a serious exploit.
- gwerbin 1mo ago
  This is the most common "not exploitable" CVE I have to deal with at work all the time. Things like buffer overruns when passing headers, but my server shouldn't be accessible to the public Internet anyway, and if it is, then we have much bigger problems. So yes it's technically exploitable IF other safeguards fail, but the reason it's irrelevant is that if those other safeguards fail, we are in deep shit anyway.
  - telotortium 1mo ago
    But if you have proper risk-based vulnerability management, you should already have classified that CVE as a lesser priority. This is something that modern LLMs should in theory make a lot easier, although I’m unsure if workflows exist to continuously build a proper architectural understanding of your systems, at least at a feasible cost.
  - bluGill 1mo ago
    Or you can just fix the issue that way if IT screws up you are not vulnerable. Or maybe next year you will decide it is useful to connect to the internet.
  - pixl97 1mo ago
    This sounds like a piss poor implementation of zero trust on your part. Security is an onion, you have lots of layers because layers peel off and fail all the time. With your current setup a single foothold gives an attacker all the lateral movement they need for full exploitation of every single thing you own blowing past the other layers.
dzhiurgis 1mo ago
Are you trying to say LLM’s are tuned to only discover unexploitable bugs?
heresie-dabord 1mo ago
CVE-2026-4I5109 - Your kitchen drawer contains forks, which can maim and/or kill. An attacker with kitchen access could access the drawer. See... CVE-1972-404: The code is written in C. ^_^
chrisweekly 1mo ago
Yes. This was the case long before LLMs sprayed the tire fire with gasoline. See e.g. this 2021 gem from Dan Abramov (React's creator) https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/
DANmode 1mo ago
Not exploitable, or not exploitable in isolation?
RetpolineDrama 1mo ago
>The vast majority of CVEs are not exploitable Perhaps in isolation. The issue is when you can chain exploits to bypass multiple layers.

bluGill 1mo ago

The majority these days seems to be real issues, but probably not exploitable. The latest LLMs are very good at reading code and finding issues where the code is wrong. They are somewhat less good at finding exploits - both because finding exploits is harder than finding code that is clearly wrong (even if not exploitable), and also because the better ones are intentionally made to not create exploits (since they don't know if you are a good or bad - they assume bad. However if I was writing this response just one year ago I would instead be saying: the majority off LLM CVS are noise where the code is correct, and often they are writing up for code that doesn't even exist. Which is to say I suspect the repo in question was generated with a year-old LLM, since they act like that. The new ones [mostly?] are much better. Still, if a modern LLM points out something you should fix it. Even if we can't figure out how to exploit it today that doesn't mean we won't figure it out in the future.

thayne 1mo ago
> I suspect the repo in question was generated with a year-old LLM I suspect there are a lot of people running inexpensive models that are searching for vulnerabilities across a lot of projects, probably in an automated way (ex with openclaw or similar) in the hopes of winning a bounty and/or noteriety.
- bluGill 1mo ago
  Most bounty programs are aware of this. Many projects have closed their bounty program in response to that type of attack.

cogman10 1mo ago

This is what I truly don't like about the CVE system. One such example is CVE-2023-45853 [1]. Zlib included in it's source an extra set of utilities and add-ons. One such utility, MiniZip, had a buffer overflow vulnerability. BAM, 8.8 CVE (was a 9, looks like they pulled it back a bit). But not one that the 99% of applications using zlib would ever be vulnerable to because almost nobody used the MiniZip utility. It was so unused that the solution for zlib was to simply remove it. I know about this one particularly because our security policy required us to do a BUNCH of pointless updates for it since zlib is in just about everything. [1] https://app.opencve.io/cve/CVE-2023-45853 https://app.opencve.io/cve/CVE-2023-45853

post-it 1mo ago
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
- cogman10 1mo ago
  Well that's the thing, to build the utilities required extra flags which were pretty rarely enabled. You can, in most distros, ultimately install minizip as a separate package but few do. It's not that useful of a utility. Most people will likely just grab the full blown "zip" application https://infozip.sourceforge.net/Zip.html https://infozip.sourceforge.net/Zip.html . Though on linux, even more people are simply using tar with a zlib extension. That's the `tar.gz` files.
  - ddevnyc 1mo ago
    I think this presents a highly fascinating scenario: 1. A vulnerability that presents itself very rarely 2. If it presents itself, it is fatal to the organization So, few targets are affected, but the outsized effect means that the overall economic impact is not insignificant. How does one keep track of that? One method is to use a sort of "kirchhoff's law" approach, similar to google page rank. The electrical analogy would be: - the attacker has a high potential, let's say 1000V. that attacker is the root of a rose tree, going from top to bottom, branching out towards the bottom. - nodes impossible to exploit present edges with infinite resistance - nodes that can be exploited present finite resistance (perhaps very low) - once a node is exploited, its node branches out to other things that now become accessible and may or may not be exploited - real economic impact presents a connection to ground, measured as 1/($economic impact) ohms resistance Once you have a structure like that, you can measure the hypothetical current that would be flowing, and measure the severity of such exploits. Sometimes a single path through a complex system can blow up vital, important parts, and this could be one way to measure it in some sort of objective manner.

pbronez 1mo ago

I once had a customer threaten to reject a delivery over a CVE. I dug into it. The CVE was that an Ocaml PostgreSQL client didn’t implement an authentication feature. I convinced the customer to accept the delivery by pointing out that (1) our app had zero lines of ocaml and (2) the feature had been implemented in the ocaml driver since the CVE was issued.

jmull 1mo ago

Yes, the CVE system is broken. LLM-generated CVEs is making it even worse. I suppose all these fake issues and the many more that have absurdly elevated severities could be considered an attack on the system itself, stripping it of credibility.

brabel 1mo ago
That's the worst case scenario right there: so many fake reports that the real vulnerabilities can no longer be reported properly and fixed quickly. Assuming some LLMs really are capable of finding serious vulnerabilities (which in my experience is absolutely the case : just let a good model run on your security code base and see for yourself) that means that we can more easily find vulnerabilities, but it's much harder to report them and be taken seriously - so the incentive to exploit such vulnerabilities instead has become much, much higher.
- pixl97 1mo ago
  Having your LLM look at the security really isn't a great option. Most users don't have unlimited budgets and can't dump the necessary time and funds needed to find these flaws. On top of that, ability to prompt about flaws makes all the difference in the world. If you know what you're doing you can get better results. Problem, very few people know what they are doing. Going back to the money/time problem, LLMs are not deterministic. Much like the day you forgot to drink coffee, running LLM systems against code can get different results where things are found or not found. That or two different things are found on two different runs (with the same code) because attention was stolen by the first issue it found. So yea, in the LLM age proof is in the exploit pudding. Who cares if you're taken seriously, if you dump out an exploit that works the seriousness is now on the defenders time and people will scramble to fix it. "But what about exploit embargos"... Well, you just found the exploit with an LLM, how many other nefarious groups do you think are already exploiting it? The age of sitting on problems is dead.

dspillett 1mo ago

> The vast majority of CVEs are not exploitable, basically noise. This is not true if you consider security-in-depth. Many of them are exploitable on their own but maybe not in combination with other issues that are as yet unknown or known but not patched everywhere. As a simple example a local privilege escalation issue that is not exploitable on a device that only I ever have access to, essentially becomes a remote root access flaw if you have untrusted or unreliable users (clients with accounts for instance) on the system. This works on a finer grain too, seemingly minor issues spread through the kernel and user space can add up to a serious exploit.

gwerbin 1mo ago
This is the most common "not exploitable" CVE I have to deal with at work all the time. Things like buffer overruns when passing headers, but my server shouldn't be accessible to the public Internet anyway, and if it is, then we have much bigger problems. So yes it's technically exploitable IF other safeguards fail, but the reason it's irrelevant is that if those other safeguards fail, we are in deep shit anyway.
- telotortium 1mo ago
  But if you have proper risk-based vulnerability management, you should already have classified that CVE as a lesser priority. This is something that modern LLMs should in theory make a lot easier, although I’m unsure if workflows exist to continuously build a proper architectural understanding of your systems, at least at a feasible cost.
- bluGill 1mo ago
  Or you can just fix the issue that way if IT screws up you are not vulnerable. Or maybe next year you will decide it is useful to connect to the internet.
- pixl97 1mo ago
  This sounds like a piss poor implementation of zero trust on your part. Security is an onion, you have lots of layers because layers peel off and fail all the time. With your current setup a single foothold gives an attacker all the lateral movement they need for full exploitation of every single thing you own blowing past the other layers.

dzhiurgis 1mo ago

Are you trying to say LLM’s are tuned to only discover unexploitable bugs?

heresie-dabord 1mo ago

CVE-2026-4I5109 - Your kitchen drawer contains forks, which can maim and/or kill. An attacker with kitchen access could access the drawer. See... CVE-1972-404: The code is written in C. ^_^

chrisweekly 1mo ago

Yes. This was the case long before LLMs sprayed the tire fire with gasoline. See e.g. this 2021 gem from Dan Abramov (React's creator) https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/

DANmode 1mo ago

Not exploitable, or not exploitable in isolation?

RetpolineDrama 1mo ago

>The vast majority of CVEs are not exploitable Perhaps in isolation. The issue is when you can chain exploits to bypass multiple layers.