JFrog Debunks Six 'Critical' SQLite CVEs as AI-Hallucinated Vulnerabilities

This is going to be a nightmare for orgs mandated to patch every CVE that shows up, no exceptions.

My first thought too. Best fix I can think of is having an agent try to reproduce the bug before a human even looks at it, but that costs money too.

Which org actually has a policy like that? Seems unworkable unless you ban open source entirely, and then CVEs stop mattering anyway.

Those orgs will just have to adapt to the new reality that some CVEs aren't real.

It's genuinely bad at my job right now. Security team is exhausted chasing these, we investigate, write a justified DNF, update records, and just hope the scanner catches up eventually. Something's gotta give.

This tanks the signal to noise ratio badly, and separating real CVEs from fake ones gets way harder. On the flip side LLMs are also finding real bugs, so I bet the blackhats are using them hard too.

The vast majority of CVEs were already low-value noise before this. I'd guess most LLM-generated ones just add more noise of the same non-exploitable kind.

All 6 CVEs in this article turned out to be completely fake when JFrog actually checked them, so calling this a real critical CVE makes no sense.

Not validating submissions is basically an open invitation to flood the whole CVE system with garbage and wreck its reliability.

This is literally what's happening with the Linux kernel becoming a CNA, someone's trying to DoS the CVE system with junk submissions.

That's exactly why big projects are rushing to become CNAs themselves, so randoms can't get unqualified CVEs assigned to them without review. Apparently Red Hat is a CNA of last resort you can hide behind too.

Daniel Stenberg has been writing about this curl problem for four years. They became their own CNA and even opened a HackerOne bounty, but had to kill the rewards because it got flooded with AI slop reports daily.

I ran this exact blog post through GPTZero and it flagged the article itself as 71% likely AI generated, including their 'Analysis Matrix' section.

Ran it through GPTZero too, different result: 63 out of 88 sentences flagged as likely AI, moderate confidence it's a human/AI mix.

Wild that a critical rating got slapped on a vuln that doesn't even exist, and maintainers still eat the triage cost regardless.

Meanwhile my actual real vulnerability reports sit unacknowledged because maintainers are too busy drowning in this nonsense.

Funny that an article about AI slop opens with a giant irrelevant AI generated slop image right at the top.

I got the sense JFrog's own code review and formatting here was mostly done by Claude too, so it's slop calling out slop.

We basically added a new kind of noise on top of ordinary human error, now it's condensed and homogenized wrongness instead of random mistakes.

LLMs are text prediction engines calculating statistically likely output, not something that understands certainty. When you need certainty, not probability, and you trust an LLM anyway, you get exactly this: a comment line mistaken for a vulnerable line, and everyone else pays the wasted-productivity bill.