The disputed reports had nonetheless entered prominent security systems. According to JFrog, the National Vulnerability Database initially marked the SQLite items as critical and a CISA Authorized Data Publisher agreed with that assessment. Red Hat at first assigned CVE-2026-51302 a 10.0 severity score before lowering it to 7.6, the research firm reported.
JFrog established an isolated testing process and examined whether the advisories’ descriptions matched the relevant SQLite versions. Several basic inconsistencies emerged. One claim relied on a function that did not exist in SQLite 3.41 and was introduced only in 2025. Another said a flaw had been fixed in version 3.51.3, yet JFrog found no corresponding change to the cited source file between versions 3.51.2 and 3.51.3.
Other reports referenced line numbers that pointed to unrelated code, invoked a function with a signature that does not exist, or claimed lines beyond the length of the relevant source file. The researchers also found that multiple proof-of-concept inputs either ran without memory errors or failed during parsing before reaching the supposedly vulnerable logic. In one case, the alleged use-after-free depended on a routine that recycles register numbers rather than freeing heap memory, making the described mechanism incompatible with the implementation.
The findings matter beyond SQLite because vulnerability feeds can trigger automatic work. A critical score may generate tickets, reorder remediation plans or prompt an automated agent to search for and patch a function. If the original advisory is fictitious, those systems can consume engineering time and may even encourage unnecessary code changes.
JFrog linked the episode to reduced manual enrichment in the wider CVE ecosystem. It said the surge in submissions led NIST to pull back from deep analysis in February 2024, while other publishers tried to address a growing backlog. The researchers argued that the submission process does not require reproduction of a bug, allowing a plausible but unsupported report to spread through downstream databases and scanners.
JFrog said it reported its conclusions to GitHub Security Advisories, Red Hat and the National Vulnerability Database. Its investigation supports verifying an advisory against source, version history and a reproducible test before treating a database severity label as proof that a flaw exists.
