SQLite Critical CVEs or LLM Slop? • Hacker News Board

Re: SQLite Critical CVEs or LLM Slop?

#101

Post by javcasas » Mon, Aug 03, 2026, 1:58 PM UTC

jodacola wrote: post #85

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.

I'm sending all my condolences out to everyone who is in a corporate environment using tools like Veracode or Snyk to automatically assess for CVEs and block merges or deployments based on "findings". My experience in such environments leads me to believe this is going to be a rough ride for those heavily locked-down enterprises, because depending on the environment, an exception of "this CVE was hallucinated by AI"…

Snyk routinely tells us that we need to upgrade urgently because they found a vulnerability in the Windows version of a package. We run everything in Linux.

Re: SQLite Critical CVEs or LLM Slop?

#102

Post by journal-myw » Mon, Aug 03, 2026, 1:59 PM UTC

Ekaros wrote: post #17

Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.

[dead]

Re: SQLite Critical CVEs or LLM Slop?

#103

Post by emj » Mon, Aug 03, 2026, 2:01 PM UTC

post-it wrote: post #70

cogman10 wrote: post #56

Earlier quoted context omitted.

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

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.

Re: SQLite Critical CVEs or LLM Slop?

#104

Post by MattPalmer1086 » Mon, Aug 03, 2026, 2:03 PM UTC

jodacola wrote: post #85

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.

I'm sending all my condolences out to everyone who is in a corporate environment using tools like Veracode or Snyk to automatically assess for CVEs and block merges or deployments based on "findings". My experience in such environments leads me to believe this is going to be a rough ride for those heavily locked-down enterprises, because depending on the environment, an exception of "this CVE was hallucinated by AI"…

In our organisation, my security team spend the majority of our effort weeding out unexploitable CVEs - which are the majority of them. But the volume is growing year on year - I don't know how sustainable it's going to be.

Re: SQLite Critical CVEs or LLM Slop?

#105

Post by myshapeprotocol » Mon, Aug 03, 2026, 2:04 PM UTC

Wild catch. This highlights just how critical precise dependency vetting is for core database engines."

Re: SQLite Critical CVEs or LLM Slop?

#106

Post by myshapeprotocol » Mon, Aug 03, 2026, 2:06 PM UTC

Wild catch. This highlights just how critical precise dependency vetting is for core database engines.

Re: SQLite Critical CVEs or LLM Slop?

#107

Post by realityking » Mon, Aug 03, 2026, 2:07 PM UTC

cogman10 wrote: post #56

flerchin wrote: post #39

Earlier quoted context omitted.

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.

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

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

Re: SQLite Critical CVEs or LLM Slop?

#108

Post by dzhiurgis » Mon, Aug 03, 2026, 2:10 PM UTC

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.

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

Re: SQLite Critical CVEs or LLM Slop?

#109

Post by taf2 » Mon, Aug 03, 2026, 2:11 PM UTC

Llm are great at things that are repeatable. Otherwise they are just like us - great at believable bullshit… a sign of true intelligence

Re: SQLite Critical CVEs or LLM Slop?

#110

Post by stellamariesays » Mon, Aug 03, 2026, 2:11 PM UTC

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.

[flagged]