JFrog security researchers published findings on August 3, 2026 asserting that a batch of SQLite CVEs posted to the GitHub repository programmervuln/cveadvisory- appear to be AI-generated content, or "LLM slop," rather than reports of genuine vulnerabilities. The advisory from JFrog's research team details how several CVEs assigned critical and high severity scores by NVD and echoed by CISA's Automated Dissemination Process (ADP) fail basic technical scrutiny when checked against the SQLite source tree. JFrog Research

The batch includes at least six CVEs targeting SQLite, all reportedly use-after-free conditions. CVE-2026-51302 was initially assigned a 10.0 Critical score by Red Hat and later downgraded to 7.6 High. NVD independently assigned it a 9.8 Critical CVSS score with a pinned CPE of SQLite 3.41.0. JFrog found that the advisory for CVE-2026-51302 claims a use-after-free in exprComputeOperands(), but that function did not exist in SQLite 3.41 and was only added in mid-2025. CVE-2026-51303 was reported as a use-after-free in ExprListDelete() back-references with a 9.8 Critical CVSS score and contradictory NVD metadata. CVE-2026-51300 was reported as a use-after-free in sqlite3ExprDelete() with a 9.1 Critical CVSS score and n/a placeholders in NVD metadata.

Three additional CVEs round out the batch. CVE-2026-51297 was reported as a use-after-free via jsonBlobEdit() with an 8.8 High CVSS score and a pinned CPE of SQLite 3.41.0. CVE-2026-51296 was reported as a use-after-free in jsonRemoveFunc with a 7.5 High CVSS score and a populated CPE of SQLite 3.41.0. CVE-2026-51304 was reported as a use-after-free via pOrderBy->nExpr post-free with a 7.5 High CVSS score, with vendor and product listed as n/a in NVD metadata. None of the disputed CVEs appear on SQLite's official advisory page.

JFrog's verification methodology was methodical. The team cloned the official sqlite/sqlite repository, checked out tags version-3.41.0, version-3.51.2, and version-3.51.3, built the releases in isolated Docker containers, and ran each advisory's proof-of-concept SQL statements under AddressSanitizer instrumentation. The results did not corroborate the claimed vulnerabilities. In one specific finding, JFrog reported that the mechanics of sqlite3ReleaseTempReg() do not involve heap deallocation, as the function only recycles register indices, contradicting the vulnerability claims tied to it.

The broader concern JFrog raises is institutional. Their research post asserts that "LLM slop" CVEs can cause organizations to waste time investigating and patching vulnerabilities that do not exist, while also polluting vulnerability databases that downstream tooling, security teams, and compliance frameworks rely on for triage and remediation prioritization. NVD flagged the batch as critical, and CISA's ADP agreed with those ratings, meaning the inflated scores propagated through automated feeds before any independent technical validation occurred. The metadata inconsistencies JFrog catalogued, including n/a placeholders for vendor and product in some entries and contradictory fields in others, were apparently not sufficient to trigger a hold on publication.

This is not the first time the CVE ecosystem has grappled with questionable SQLite entries. CVE-2024-0232, a heap use-after-free in jsonParseAddNodeArray() in sqlite3.c, and CVE-2025-6965, a memory corruption flaw, are both documented in vendor advisories from 2025. Those CVEs, however, correspond to identifiable code paths. The distinction matters because the current batch's defects are structural: functions referenced in the advisories either did not exist in the pinned version or operate on mechanisms that do not perform the memory operations the advisories describe.

The pinned CPE of SQLite 3.41.0 across multiple entries is itself a red flag. SQLite 3.41.0 was released in early 2023. Pinning a 2026 CVE to a two-year-old release, while simultaneously referencing functions that only landed in the codebase in mid-2025, produces an internally inconsistent advisory. That inconsistency apparently survived whatever review NVD applied before assigning severity scores.

In this author's view, the episode exposes a structural weakness in the CVE pipeline that the industry has been slow to address. NVD and CISA's ADP operate at scale, processing thousands of entries, and they lean on the CVE Numbering Authority (CNA) ecosystem for initial vetting. But when a GitHub repository can submit advisory text that reads plausibly enough to receive 9.8 Critical ratings and propagate through CISA's feeds without anyone confirming that the named function exists in the pinned version, the bottleneck is not throughput. It is verification. AddressSanitizer builds and source-tree lookups are not exotic techniques. They are the baseline steps any competent security team would perform before triaging a use-after-free claim. The fact that these steps happened after publication, in a JFrog blog post rather than in the NVD intake process, is the actual story here.

The cost is not merely hypothetical. Every security operations center that ingests NVD feeds programmatically would have received these entries as critical-priority items. Triage queues would have been reweighted. Patching cycles would have been interrupted. For a vulnerability that does not exist, in a function that did not exist, in a version pinned two years before the function was written. The signal-to-noise ratio in vulnerability management is already a chronic pain point. AI-generated advisory text, plausible in structure and technical in vocabulary, degrades that ratio precisely where automated systems are least equipped to catch it: at the boundary between human-authored and machine-generated content, where existing quality controls assume a human author's accountability.

JFrog's research post does not speculate on the motivation behind the programmervuln/cveadvisory- repository or identify its operator. What it does establish is that the technical claims in the disputed advisories do not hold up under standard verification, that the severity ratings assigned by NVD and endorsed by CISA's ADP were not warranted by the underlying code, and that the pattern of internally inconsistent metadata, nonexistent functions, and implausible memory-operation descriptions is consistent with LLM-generated text rather than genuine vulnerability research. The implication for the CVE ecosystem is straightforward: the intake and scoring pipeline needs a verification layer that does not assume good faith, because the cost of not having one is borne by every downstream consumer of the data.