Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite Critical CVEs or LLM Slop?

research.jfrog.com

Post reply on HN
Print view View original

141–150 of 407 posts

Re: SQLite Critical CVEs or LLM Slop?

#141

Post by chrisweekly »

flerchin wrote: post #39
ChrisMarshallNY wrote: post #4

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult. But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

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.

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/

Re: SQLite Critical CVEs or LLM Slop?

#142

Post by mwkaufma »

bluGill wrote: post #72
fabioborellini wrote: post #48

Earlier quoted context omitted.

And this year, some of the reports suddenly got good and meaningful. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ So the agents started doing something useful after a period of filling mailing lists and bug bounties with slop. Sound good, but that's not entirely a good thing. The volume of good reports is a burden as well, and it's likely that long-lasting open source C/C++ projects have legitimate vuln…

The real question is will [when will] these vulnerabilities get fixed faster than they can be found. LLMs are finding a lot of real bugs that have existed without being noticed for 20+ years. It is generally expected [hoped] that in a short time all those 20 year old bugs will be fixed and LLMs will settle down to just things introduced in the last month (or perhaps this pull request) and thus be manageable.

Won't an LLM, prompted for a CVE report, always hallucinate one even if it isn't there? Why would they "settle down"?

Re: SQLite Critical CVEs or LLM Slop?

#143

Post by thayne »

delusional wrote: post #118
realityking wrote: post #107

Earlier quoted context omitted.

IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.

Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really. If you keep driving the "seperate the packages" angle you end up with is-odd, and th…

Even more than that, a lot of vulnerabilities require untrusted input to exploit, but the library or executable is usually only used with trusted input. For example, suppose the chacha20 function had a vulnerability that was exploitable with a malicious secret key, but you only call it with your own, definitely not malicious, key. The vulnerability doesn't impact you, but your security policy might still require you to update. And no amount of splitting the package will help with that.

Re: SQLite Critical CVEs or LLM Slop?

#144

Post by DANmode »

flerchin wrote: post #39
ChrisMarshallNY wrote: post #4

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult. But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

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.

Not exploitable, or not exploitable in isolation?

Re: SQLite Critical CVEs or LLM Slop?

#145

Post by jimktrains2 »

ptx wrote: post #92
mahogany wrote: post #50

Earlier quoted context omitted.

The comment is making fun of a Claude-ism where it becomes super “honest” about stuff. It’s a joke but there is an underlying real effect where this type of language is psychologically manipulative and I would guess makes people believe LLMs output more than if it didn’t use “honest” (or “load bearing” or whatever super serious important sounding word).

Or maybe they didn't train it that way to be manipulative (although it's certainly a plausible explanation) but simply as an accidental artifact of trying to make it give honest answers? LLM-generated images sometimes includes text from the prompt as literal text in the image, so perhaps this is the same sort of artifact? If they've told it to be honest, it responds by talking about being honest instead of actually b…

> accidental artifact of trying to make it give honest answers?

If it's not giving honest answers that implies it's purposely being deceitful, which it isn't capable of. Right?

Re: SQLite Critical CVEs or LLM Slop?

#146

Post by telotortium »

gwerbin wrote: post #130
dspillett wrote: post #94

Earlier quoted context omitted.

> 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…

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.

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.

Re: SQLite Critical CVEs or LLM Slop?

#147

Post by TheDong »

gmueckl wrote: post #127
delusional wrote: post #118

Earlier quoted context omitted.

Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really. If you keep driving the "seperate the packages" angle you end up with is-odd, and th…

At least for native binaries it's not too hard to write a scanner that extracts symbols from the binaries and checks them against the symbol names of the vulnerable code. If the code is properly dead and got pruned by the linker, it cannot cause any problems.

Yes it can cause you troubles, even if you don't link to it. Just having a vulnerability scanner (incorrectly) flag it can cause you numerous problems.

Say you distribute your application to a customer and link against libzip, and that customer points to the minizip 8.8 CVE above and says "if you don't fix this vulnerability our scanner is flagging, we are required to stop using your product", that'll cause you plenty of problems even though you don't use nor provide any way to reach the vulnerable code.

That sort of blind CVE adherence is so common in the industry that it's usually easier to do meaningless updates than fight back.

Re: SQLite Critical CVEs or LLM Slop?

#148

Post by mavleop »

Thankfully I’m seeing other people mention that this article itself seems AI-generated. While there's less proof, i suspect that the actual analysis was done by an llm as well. So while i like to dunk on hallucinations as much as the next guy, who's to say this analysis doesnt have them too?

(for the record, i think the cve's are probably bogus, i just think there's an inherent problem with debunking slop with slop)

Re: SQLite Critical CVEs or LLM Slop?

#149

Post by telotortium »

ymir_e wrote: post #132
CodesInChaos wrote: post #99

Earlier quoted context omitted.

I'm sure if somebody hired him for a pentest it'd cost more per vulnerability found.

I think his point was more that he didn't believe it was difficult to find these issues. Could be Dunning-Kruger, but if AI models continue to get better this trend will surely continue.

1. George Hotz exhibits strong signs of Dunning-Kruger in most things he does nowadays.

2. Even in exploit development, his original field, he might be able to find vulnerabilities in mature, well-maintained software with security programs. But would he charge $20k or more for that service? Say it with me, Claude: “Absolutely!”

Re: SQLite Critical CVEs or LLM Slop?

#150

Post by stackghost »

emj wrote: post #103
post-it wrote: post #70

Earlier quoted context omitted.

But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.

You do not run it as root, all you get is the possibility to crash or execute code. Nodes that handle such things are all heavily locked down.

>all you get is the possibility to [...] execute code

Anyone who's ever done even a beginner CTF knows that achieving code execution is a big deal.

Post reply on HN