Six purported SQLite vulnerabilities, initially rated from 7.5 High to 9.8 Critical, were not reproducible bugs at all. JFrog’s July 30, 2026 investigation found that the advisories cited nonexistent code, impossible source locations, and proof-of-concept inputs that either failed to parse or did not crash SQLite under memory-error detection.
The six records—CVE-2026-51296, CVE-2026-51297, CVE-2026-51300, CVE-2026-51302, CVE-2026-51303 and CVE-2026-51304—reached the National Vulnerability Database before their CNA withdrew them on July 31. SQLite now labels each one “Not a bug in SQLite” and describes them as unreproducible, apparent AI hallucinations. That is an attribution, not a proven account of who authored the reports.
Six SQLite CVEs Reached NVD Before Rejection
The records originated in the public programmervuln/cveadvisory- GitHub repository, which published the SQLite advisories amid a larger collection of CVE-named submissions. JFrog security researcher Afek Berger reported that the six SQLite entries were assigned CVEs, entered NVD workflows and received enrichment from CISA’s Authorized Data Publisher program before the withdrawal. NVD’s preserved record for CVE-2026-51302 shows prior CISA ADP scoring and CPE product metadata despite its current rejected status.
That sequence matters operationally because a CVE is not just a web page. Once a record arrives in vulnerability feeds, scanners can flag it, ticket systems can open remediation work and security teams can spend time chasing a patch for a bug that does not exist. The supplied sources do not quantify how many of those downstream systems retained alerts from these six records.
JFrog tested the claims the less glamorous way: against the source code and actual binaries. Researchers checked out the SQLite versions named in the advisories, compiled them in isolated Docker containers, then ran each supplied SQL proof of concept under AddressSanitizer, a runtime tool designed to catch memory-safety failures. The investigation says several payloads were invalid SQL or JSON, while others completed without an ASan-detected crash.
One record illustrates the gap between the label and the evidence. CVE-2026-51302 was presented as a 9.8 Critical heap use-after-free, alleging that sqlite3ReleaseTempReg() left a dangling pointer later read by exprComputeOperands(). JFrog found that exprComputeOperands() did not exist in the SQLite 3.41 release named by the advisory; it was added only in mid-2025. The alleged first function also recycles register indexes rather than freeing heap memory, undercutting the proposed use-after-free mechanism.
“Not a bug in SQLite.”
SQLite’s maintained CVE page applies that verdict to all six records and calls them “apparent AI hallucinations.” The maintainers also note that they generally regard CVE counts as an unreliable indicator of bugs affecting typical SQLite deployments. That broader position does not automatically invalidate every future SQLite CVE; here, the decisive evidence is the failed source review and failed reproduction attempts.
The technical defects varied, but they shared a pattern that should have stopped the reports before severity scoring: functions absent from the cited version, wrong function signatures, fabricated fixes, references to unrelated code and line numbers that did not fit the release. JFrog says it found those failures across the six reports, including claims rated severe enough to prompt immediate remediation in many organizations.
CVE-2026-51302’s severity also shifted before rejection. JFrog observed that Red Hat initially assigned it a 10.0 Critical score, then reduced it to 7.6 High. The original advisory’s own framing was 9.8 Critical. Precision is not the same as verification: a decimal score can make an invented failure mode look strangely official.
NVD does not erase rejected records. Its page for CVE-2026-51296 preserves the previous SQLite vulnerability description while marking the entry rejected because the CNA determined it was not a security issue. That archival choice is useful for audit trails, but it means teams cannot assume an old scanner finding remains valid merely because its CVE page still exists.
This account is principally based on JFrog’s audit and SQLite’s status page; JFrog’s broader claim that 54 of 55 advisories in the originating repository were fabricated has not been independently quantified by the other supplied sources. But the six SQLite records have a clear final status: no patch to deploy, no bug to reproduce, and six false positives that security teams should close rather than keep escalating.
Key Takeaways
- Six purported SQLite CVEs were withdrawn on July 31, 2026 after their CNA determined they were not security issues.
- The affected records were CVE-2026-51296, -51297, -51300, -51302, -51303 and -51304.
- The advisories initially carried reported severity scores ranging from 7.5 High to 9.8 Critical.
- JFrog found that the reports cited absent code, incorrect logic and non-working proof-of-concept payloads.
- Rejected CVE records remain available in NVD, so teams should close prior scanner findings and remediation tickets tied to them.
Further Reading
- SQLite Critical CVEs or LLM Slop? — JFrog’s July 30, 2026 investigation of the six unreproducible SQLite reports.
- SQLite Vulnerabilities — SQLite’s maintained status page for the rejected CVEs.
- NVD: CVE-2026-51302 — Preserved NVD record showing rejection and prior enrichment.
- NVD: CVE-2026-51296 — A second rejected SQLite record retained by NVD.
- programmervuln/cveadvisory- repository — The public repository that hosted the advisory files.
Originally published on novaknown.com
Top comments (0)