SQLite Critical CVEs or LLM Slop. JFrog investigates whether reported vulnerabilities are real or AI hallucinations.

A security researcher runs a batch of automated CVE analysis across a popular open-source database. The tool returns a list of critical vulnerabilities with CVE identifiers, reproduction steps, and severity scores. The researcher files the reports. Then a second team tries to reproduce them and finds nothing. No crash. No memory corruption. No vulnerable code path. The CVEs were confident, detailed, and wrong.

That is the situation JFrog's research team investigated when they looked at a wave of reported SQLite vulnerabilities. Their analysis, published at research.jfrog.com, asked a question that more security teams should be asking: are these real bugs, or are they LLM-generated noise that made it through the submission process?

Three tiers of AI-assisted security research compared

The JFrog investigation is useful because it forces a comparison that the industry has been slow to make explicit. There are three distinct approaches to AI-assisted vulnerability research right now, and they produce very different results.

Approach	How AI is used	Human verification step	False positive risk
AI-assisted, human-led	Code summarization, pattern matching, initial triage	Researcher reproduces every finding manually before filing	Low. The human catches hallucinated code paths before they leave the team.
AI-generated, lightly reviewed	Full vulnerability write-up including PoC, severity assessment, CVE draft	Cursory review, no reproduction attempt	High. The write-up reads credibly but the underlying claim is never tested against the actual binary.
Fully automated pipeline	End-to-end: scan, analyze, write, submit	None	Critical. Volume is high, reproduction rate is close to zero for the fabricated findings.

The SQLite CVEs under scrutiny appear to fall into the second or third category. The reports exist. The CVE identifiers are real. The underlying vulnerabilities are not verifiable.

For a security engineer running triage, the verdict here is unambiguous: treat any CVE sourced from an automated pipeline as unconfirmed until you can reproduce it in a controlled environment. For a developer deciding whether to patch urgently, the same logic applies - a high CVSS score on a phantom bug is not a real threat, and patching for it may introduce unrelated regressions.

The actual cost of acting on phantom CVEs

The money cost is the smallest part. An engineering team that drops two sprint days to investigate a critical SQLite CVE, builds a reproduction environment, audits calling code, and prepares a patch for a vulnerability that does not exist has lost approximately 16 to 20 hours of senior engineer time. At average compensation rates for senior security engineers, that is a real number. But it is not the number that should concern teams most.

The larger cost is calibration erosion. When a team investigates three phantom CVEs in a row and finds nothing, the instinct to deprioritize the next critical report grows. That is the moment a real vulnerability slips through. The false positive problem in LLM-assisted security research does not just waste time. It trains teams to discount alerts, which is the opposite of the intended outcome.

There is also a downstream reputational cost to the CVE ecosystem itself. The National Vulnerability Database exists because the security community agreed to share verified findings in a structured way. A wave of LLM-generated submissions degrades the signal quality of the entire database for every team that depends on it. That is a collective harm, not just an individual one.

Setup friction for verification is worth quantifying too. Reproducing a claimed SQLite memory corruption bug requires:

1. Pulling the exact version of SQLite referenced in the CVE
2. Building with the compiler flags and sanitizers the reporter claims were used
3. Running the claimed input or query sequence
4. Confirming whether ASAN, Valgrind, or equivalent tooling surfaces the described behavior
5. Cross-referencing the SQLite commit history to confirm the code path exists

That process takes two to four hours for a skilled engineer who knows the codebase. For a team unfamiliar with SQLite internals, it takes longer. Multiply that by the number of unverifiable reports in a given quarter and the budget impact becomes significant.

What the Hacker News discussion surfaced

The problem is that LLMs are really good at writing vulnerability reports. They know the format, the severity language, the CVE boilerplate. They just don't know whether the vulnerability is real.

That comment, representative of the thread's general direction, identifies the exact mechanism. A model trained on security advisories, CVE databases, and bug bounty writeups will produce output that is structurally indistinguishable from a genuine report. The format is correct. The severity language matches what reviewers expect. The proof-of-concept code compiles. It just does not trigger the bug it claims to demonstrate, because the bug was inferred from patterns in training data rather than observed in the actual target.

This is not a GPT-5.6 or Claude Opus 5 problem specifically. It is a property of any language model applied to a task that requires ground-truth verification of a physical system. The model can describe what a buffer overflow looks like in C code. It cannot confirm that a specific SQLite query actually causes one without running the query against the binary. That second step requires an execution environment the model does not have access to, and more importantly, requires the researcher to care whether the output is accurate before filing.

The JFrog analysis matters precisely because it shows the problem at the submission layer. The question is not whether AI can help find vulnerabilities - it demonstrably can, in the hands of researchers who treat its output as a starting point rather than a conclusion. The question is what happens when the starting point gets submitted directly to a public database as a confirmed finding.

How LLM hallucination behaves differently in security contexts

A useful analogy: imagine asking someone who has read every car repair manual ever written to diagnose a problem with your specific car, without letting them open the hood. They will give you a plausible answer based on the symptoms you describe, cross-referenced with every similar symptom they have encountered in their reading. Most of the time, the answer will be directionally useful. Some of the time, they will confidently describe a part that does not exist in your model year.

In most domains, a confident wrong answer is annoying. In security research, it has consequences for everyone downstream. The CVE database is infrastructure. When it contains phantom entries, every tool that ingests it - dependency scanners, SAST pipelines, patch management systems - treats those entries as real and routes real human attention toward them.

Tools like Cursor and GitHub Copilot have pushed developers toward treating model output as a starting point for code review rather than a final answer. The security research community is arriving at the same lesson through a harder path. The model output is a hypothesis. Confirming the hypothesis requires work the model cannot do for you.

The technical distinction that matters here is between syntactic plausibility and semantic correctness. An LLM operating on source code can identify patterns that look like known vulnerability classes - integer overflow, use-after-free, SQL injection. It cannot reliably distinguish between a pattern that matches a known class and an actual exploitable instance of that class. Those are different tasks. The first requires pattern recognition. The second requires understanding execution state, memory layout, and runtime behavior in ways that static analysis of text does not support. For more on how this distinction plays out in practice, see our post on separating LLM hype from reality.

Things to confirm before acting on any AI-sourced CVE

• Check whether the reporter has provided a working proof-of-concept that you can run against the exact version cited
• Verify the code path exists in the SQLite commit history at the version specified
• Confirm the CVE was acknowledged or commented on by the SQLite maintainers or a known independent researcher
• Run the claimed reproduction steps in a sanitized environment with ASAN enabled before escalating internally
• Cross-reference the finding against the official SQLite CVE list to see whether the maintainers recognize it
• Check whether the submitting researcher has a verifiable track record of confirmed findings in other projects
• If your team uses an AI-assisted coding or review tool in the security pipeline, document at which step human verification occurs and whether that step includes reproduction