SQLite Critical CVEs or LLM Slop? (JFrog blog) [LWN.net]

The JFrog blog examines some reported vulnerabilities in SQLite, some of which made their way into high-profile vulnerability databases, that turned out to be entirely fabricated by LLMs.

These LLM slop CVEs can cause organizations to waste time investigating and patching vulnerabilities that do not actually exist, as well as polluting vulnerability databases. In environments where Critical vulnerabilities are automatically prioritized or tickets are opened based on vulnerability scores, such fabricated CVEs can turn into a real burden.
In environments where AI is used to automate vulnerability triage and remediation this becomes even more concerning. An AI agent that encounters a fabricated CVE may attempt to locate the vulnerable function, generate a patch, or recommend changes based on code that does not even exist. Instead of helping security teams remediate real vulnerabilities, it can lead them down a completely wrong path, potentially introducing unnecessary changes and wasting time.

to post comments

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 15:07 UTC (Mon) by geofft (subscriber, #59789) [Link] (19 responses)

As I wrote here a couple of years ago:

I actually think that this is, essentially, a DoS vulnerability in the CVE process itself. Anyone can submit an entry into a database that gets insufficiently validated and causes other people to have to scramble and respond and maybe makes their automated systems break. That's unauthenticated input causing denial-of-service attacks!

If you have any sort of policy that all CVEs have to be patched, as apparently many large companies do, you need to treat that policy itself as a vulnerability and remediate it. CVEs are fine as a source of input to a system for determining what actual vulnerabilities you care about, but you need to validate that input. (And that gets you the opportunity to do a bunch of other useful things like determine that a CVE is in fact technically sound but applies to a feature or a way of using a library that you're not using.)

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 15:28 UTC (Mon) by neverpanic (subscriber, #99747) [Link] (1 responses)

> If you have any sort of policy that all CVEs have to be patched, as apparently many large companies do, you need to treat that policy itself as a vulnerability and remediate it. CVEs are fine as a source of input to a system for determining what actual vulnerabilities you care about, but you need to validate that input. (And that gets you the opportunity to do a bunch of other useful things like determine that a CVE is in fact technically sound but applies to a feature or a way of using a library that you're not using.)

This, so much this. Way too many consumers don't do anything beyond "this has a 9.8 CVSS score by NiSt VulNriCHmeNT, plzfix11!!!" these days, not realizing that these scores make some very conservative assumptions (for lack of better knowledge of the actual target system) that mostly don't hold on a modern Linux these days, e.g., the absence of stack canaries, ASLR, or other standard hardening measures.

If the endless wave of CVEs we are seeing leads to consumers (read: companies) adopting better practices in what's actually worth fixing, that would be a very good outcome.

Unfortunately I doubt it'll happen, and instead we'll just see everybody rush to deploy quicker.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 15:37 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

What this episode says is that trust in the software industry ability to clean up its own messes is at an all-times low, even among the industry itself. Just patch and rebuild and hope it works as it should this time.

Laymen have no trust in software people and software people are all too aware of their own past shortcuts.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 15:58 UTC (Mon) by smoogen (subscriber, #97) [Link] (14 responses)

If you have any sort of policy that all CVEs have to be patched, as apparently many large companies do

I have found that a lot of this seems pushed from outside of the company.

You want to keep your business insurance for something? Make sure you have a full CVE patch policy
You want to keep your business access to banking? Make sure you have a full CVE patch policy
You want to keep your business access to certain customer markets? Make sure you have a...
You want to be able to sue someone because they reneged on the above...

The bigger businesses get the most audits from insurers, customers, regulators, etc because they also have the most contracts. They then start pushing this down the chain because it doesn't matter if it is a third level provider which was the initial cause of whatever event they are dealing with..

None of this invalidates (and really just emphasizes what @geofft also said:

I actually think that this is, essentially, a DoS vulnerability in the CVE process itself. Anyone can submit an entry into a database that gets insufficiently validated and causes other people to have to scramble and respond and maybe makes their automated systems break. That's unauthenticated input causing denial-of-service attacks!

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 17:35 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (13 responses)

I'll _MAYBE_ buy insurance requirements and I'll _MAYBE_ buy clueless customers, particularly if the clueless customers are governments. If the clueless governments are from particularly clueless places like the EU, I wouldn't even be surprised.

But I will not buy banking access. Business checking accounts are extremely easy to open. They are not concerned with your internal IT infrastructure whatsoever. And, the implausibility of that claim makes me suspicious that the other claims are actually true, even if they are plausible.

Banking

Posted Aug 3, 2026 18:01 UTC (Mon) by corbet (editor, #1) [Link] (6 responses)

I am not the person you are replying to, so I may be way off but ... "banking" for a business goes way beyond opening a checking account. If you, for example, accept credit cards, they suddenly become far more interested in your security practices. I would not be surprised to learn that this happens for businesses seeking credit as well.

Banking

Posted Aug 3, 2026 19:15 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> If you, for example, accept credit cards, they suddenly become far more interested in your security practices. I would not be surprised to learn that this happens for businesses seeking credit as well.

FYI, "banking" != "payment processing"

(you may see both provided under the same roof, but they are very different sets of services with very different requirements)

"Seeking credit" is also distinctly different.

Banking

Posted Aug 3, 2026 19:29 UTC (Mon) by corbet (editor, #1) [Link] (4 responses)

You know, when people start filling the space with tedious quibbles like this, I strongly regret having ever added the ability to post comments to LWN.

Is your real point that the original poster should have said "financial services" rather than "banking"?

Banking

Posted Aug 3, 2026 19:54 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Is your real point that the original poster should have said "financial services" rather than "banking"?

I don't know if they had meant to use the word "banking" as a synonym for generic "financial services" or the more narrow "bank account" sense. Either way, they were factually incorrect, only certain types of financial service providers place any sort of obligations upon a business' internal IT practices.

The main ones that do are payment processors (the PCI-DSS is quite a beast, as I'm sure you are well aware) and providers of certain types of insurance looking to lessen the risk of taking you on as a customer. But simply opening or accessing bank accounts/lines of credit, most types of insurance, brokerages, etc etc? Nope.

Banking

Posted Aug 3, 2026 23:15 UTC (Mon) by WolfWings (subscriber, #56790) [Link] (1 responses)

For any company interacting with the internet they are all functionally one and the same. You are (accidentally I hope) XKCD/2501'ing here.

"Banking" access is a well-understood catchall for payment handling, payroll, etc, all of which are the source of many if not most audit requirements for any given company. And yes, all of those require opening an account, so technically that's rolled up in things too at some layer I suppose even.

Anyone that works B2B IT support runs into this constantly, doesn't matter if you're a cloud provider, storage vendor, networking gear, VoIP service, whatever, it's where easily 50% or more of the "Hey so our auditor reported these CVE's..." tickets come from if you inquire is just a non-technical "banking" response back.

Banking

Posted Aug 4, 2026 12:30 UTC (Tue) by pizza (subscriber, #46) [Link]

> "Banking" access is a well-understood catchall for payment handling, payroll, etc, all of which are the source of many if not most audit requirements for any given company.

As an entire blanket category, sure. But my entire point is that the sub-categories are *very* different and shouldn't be lumped together.

These are the entire "IT requirements" for most businesses that take credit cards:

* Working internet connection and power source for the payment-processor-supplied(+managed) payment terminal

Meanwhile, these are the entire "IT requirements" for nearly everything else:

* Internet-capable device with a relatively up-to-date web browser

That's it.

Now if you run things in-house instead of contracting it out to specialists (because this saves you money at larger scales), sure, there _may_ be additional requirements for _some_ sub-categories, but the specific details vary considerably. The critical question is "who is on the hook should $bad_thing occur". If it's an external entity (eg merchant/payment processor or insurance company) then they may contractually impose requirements as a condition of service.

Of course there's also increasing levels of regulatory crap you have to deal with the more stuff you do in-house, but that's imposed by the government, not a "financial services" provider.

(BTW, most of my career has been spent at small companies for whom *I* was effectively IT department. So I'm more than a little familiar with this crap)

Banking

Posted Aug 6, 2026 19:49 UTC (Thu) by smoogen (subscriber, #97) [Link]

My apologies Jonathan for starting this.. I should have been clearer about payment processing and financial services versus 'banking access'.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 18:19 UTC (Mon) by hunger (subscriber, #36242) [Link] (5 responses)

Most governments are way less clueless than you make them out to be. Companies have a way worse track record here.

Go and check the rules you need to follow when accepting credit card data from customers... you will be surprised how "banking" can be a challenge to IT departments.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 2:24 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (4 responses)

payment card processing != banking

Visa, Mastercard, American Express, and Discover are not banks. Discover is owned by a bank -- Capital One -- but that's only because Capital One acquired Discover, and the Discover Network is still its own "thing" inside of Capital One.

And, before you start to say otherwise, no, you do not have to have an agreement with a bank to take credit cards. You can just use Stripe. And send your funds to a brokerage account even instead of a normal bank account if that floats your boat.

Now, you _ARE_ correct that the payment card industry promulgates a bunch of really stupid IT requirements. Those idiotic requirements are one big reason I would never in 10 billion years take payment cards. The other big reason would be not wanting to lose over 3% of my gross revenue to bullshit card processing fees. Either reason alone would be sufficient for me to "nope" the fark right out of there if anyone ever tried to convince me to take payment cards.

Maybe LWN should stop taking payment cards and use Zelle instead. Instant 3% gross revenue increase unless subscribers decide it's too annoying. So to avoid that maybe keep taking the cursed cards but pass on your processing fees to us and let us avoid them by using Zelle or a check.

I get 4%+ cash back on everything I buy as a consumer, and that's great for me, but I'm not an idiot. I know that "cash back" money is coming out of merchants' pockets. I know payment cards are evil and would love to see merchants no longer have to suffer an invisible tax from taking them. Down with all four of the payment card networks, thieving bastards every one.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 2:47 UTC (Fri) by dskoll (subscriber, #1630) [Link] (1 responses)

Maybe LWN should stop taking payment cards and use Zelle instead

Zelle is USA-only. So LWN would still need to take cards (or find other ways) for non-US subscribers to pay.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 4:28 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link]

Early Warning Services is working on fixing that: https://www.prnewswire.com/news-releases/zelle-heads-to-i...

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 6:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Zelle does not have proper customer _and_ merchant protection. It also does not have a proper payment story (how do you link a Zelle transaction?).

> Zelle® Heads to India, Unveils ZelleUSD℠ Stablecoin For Other Markets

It's dead. Cryptocrap kills everything.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 8, 2026 2:59 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

In general, Zelle is highly questionable for almost all purposes. The banks like to pretend[1] that Regulation E does not apply to Zelle, which in plain English means "no chargebacks, no refunds, and we specifically don't want to hear about how you thought he really was the deposed prince of Nigeria." I wouldn't touch Zelle for anything other than giving money to a personal friend or family member.

[1]: See https://www.bitsaboutmoney.com/archive/regulation-e/ for a more precise explanation of what the banks claim and how legally plausible it is. But note that the average consumer is not in a great position to start a legal battle with the average bank.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 16:33 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Entirely agreed, I've been saying the same for a long time to lots of people not even willing to listen to this. They feel forced by compliance processes which rely on signals out of thin air which CVE are.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 19:23 UTC (Mon) by kleptog (subscriber, #1183) [Link]

In practice I find there is an easy filter: if there is no fix version then it is non-actionable and can be ignored.

There are only a handful of components that are publicly visible so you have pay a little more attention there. Most CVEs you can just ignore other than by deploying a new version every now and then.

The solution is obvious

Posted Aug 3, 2026 15:50 UTC (Mon) by ballombe (subscriber, #9523) [Link] (2 responses)

The solution is obvious. Use a LLM to filter invalid CVE!

The solution is obvious

Posted Aug 3, 2026 16:54 UTC (Mon) by willy (subscriber, #9762) [Link]

AIVCVEaaS

(AI Vetted CVEsa s a Service)

The solution is obvious

Posted Aug 6, 2026 14:32 UTC (Thu) by MrWim (subscriber, #47432) [Link]

You joke, but this is where I've found LLMs to be most helpful on a day to day basis.

We run osv-scanner on our (Ubuntu based) docker images. Among other things it looks at the installed list of packages and warns on any CVEs that affect these packages. The vast majority affect code that is either not installed[^1] or not called[^2] by our application. We create an ignore rule for each CVE with a reason detailing reasons why it's not relevant or sufficiently low risk to ignore with an expiry date.

It's tedious work.

I created an LLM prompt which automates the bulk of this, looking at the CVEs, and the installed files and what code is used. The result is better than when a human was doing it all because the LLM doesn't find it tedious - it just does it. The result needs to be carefully reviewed, and the agent does make mistakes, but where it does you just point it out and it will fix it. The most annoying bit is approving all the commands the agent wants to run.

P.S. Jon: I love the new Markdown option. Please consider supporting references as well[^3].

[^1]: CVEs are automatically imported into the ubuntu CVE tracker from upstream and are associated with a source package, rather than a binary package. This means that e.g. CVE-2025-5222 in the genrb binary from icu-devtools is warned against even though we've only got the libicu70 installed.

[^2]: I'm excited about systemd's work moving towards using dlopen() to make more dependencies optional. I'd love the same approach applied to python3-pil, so I don't need to have unused parsers installed. I'm sick of reviewing irrelevant freetype/libtiff CVEs.

[^3] I find references helps with my writing as I get distracted and go off on a tangent. References help because there's somewhere I can store the tangents that don't distract from the main thrust of the text.

JFrog's Artifactory used in the OpenAI hacking of Hugging Face

Posted Aug 4, 2026 8:10 UTC (Tue) by ehiggs (guest, #90713) [Link] (1 responses)

I have to wonder if JFrog is putting out a blog article about CVEs and LLMs to try and pollute search results so it's harder to see the absolutely immense CVE where Artifactory was not validating tokens when the user requests a refresh token: https://app.opencve.io/cve/CVE-2026-65616

El Reg article here: https://www.theregister.com/security/2026/07/28/jfrogs-0-...

JFrog's Artifactory used in the OpenAI hacking of Hugging Face

Posted Aug 5, 2026 18:25 UTC (Wed) by ejr (subscriber, #51652) [Link]

If they really wanted to do that, they'd follow OneUptime's example of generating a massive number of "how to" guides as bulk-posted blog articles. Doesn't help that much of the "how to" information technically is correct, and that's an example of next-generation SEO via LLMs. Places can drown out other voices by generating massive volumes of correct information related to the topic and simply omitting the embarrassing aspects.

Feeding LLM/AI slop instructions as good practice policy

Posted Aug 4, 2026 14:09 UTC (Tue) by JeogioVilavoni (subscriber, #185081) [Link]

I came across this article about a developer with Gnome Extensions @ EGO where he developed a set of instructions to follow feed web crawler bots.

https://blogs.gnome.org/jrahmatzadeh/2026/07/27/ego-ai-re...

To me it is a great example to build upon as for the growing problem of CVE created slops.

Creating a policy along those lines to slow down & stop this madness. We care about the health of our security experts :)

when conservative estimation...

Posted Aug 5, 2026 12:02 UTC (Wed) by grmnsftphr (subscriber, #178591) [Link]

...is giant CVE score inflation.

And yes, I've been inflicted by CVE slop too. The plague on all their houses.