CVE-2026-51302 and Five More Fake SQLite CVEs Cited Code That Doesn't Exist

TL;DR

---

On July 30, 2026, JFrog Security Research published an analysis concluding that six CVEs filed against SQLite were entirely fabricated.
A CVE is the common identifier assigned to software vulnerabilities. All six carried High-to-Critical CVSS severity scores between 7.5 and 9.8 on the National Vulnerability Database (NVD), the US government’s vulnerability catalog.

SQLite’s author Richard Hipp had started receiving emails from reputable security analysts asking about the fictitious CVEs.
When JFrog researcher Afek Berger checked the six reports, every one of them collapsed the moment it was compared against the source code of the version it claimed to affect. Digging into the reporting GitHub account, 54 of its 55 advisories, including ones against projects other than SQLite, turned out to be fabricated. The one remaining report contained a real bug, but its CVE metadata was unverified.

Hipp responded by opening a thread titled “Fake CVEs against SQLite” on the official forum.
MITRE, the US non-profit that administers CVE IDs, rejected the batch on July 31, and never contacted the SQLite developers in the process.

All six point at code that doesn’t exist

The six reports are CVE-2026-51296, 51297, 51300, 51302, 51303 and 51304. Each claims a memory-corruption flaw in SQL statement processing or the JSON functions. Their scores at the time of NVD publication were as follows.

CVE	CVSS as published	Claim	Contradiction JFrog found
CVE-2026-51302	9.8 Critical	Use-after-free in expression evaluation	Cites exprComputeOperands(), which doesn’t exist in the 3.41 series it targets. The function was added in mid-2025
CVE-2026-51303	9.8 Critical	Flaw “fixed” in 3.51.3	The diff between 3.51.2 and 3.51.3 contains no changes to src/expr.c at all
CVE-2026-51300	9.1 Critical	Memory corruption	The cited lines 1012 and 1026 are a comment and a memory-allocation call
CVE-2026-51297	8.8 High	JSON handling flaw	Cites jsonBlobEdit(), which doesn’t exist in the targeted 3.41.0
CVE-2026-51296	7.5 High	Flaw at lines 3555–3575 of json.c	json.c in 3.41.0 is only 2,706 lines long
CVE-2026-51304	7.5 High	Memory corruption	The function signature as described doesn’t exist

A use-after-free is a bug where a program keeps using memory it has already freed; when exploitable, it can lead to crashes or arbitrary code execution. The claims follow plausible-looking patterns, but the code they point at was never there.

Running the attached proof-of-concept SQL reproduced no crashes at all.
Feeding the advisory text to GPTZero, an AI-writing detector, returned an AI-generated verdict. Combining that with how the reports fell apart, JFrog suggested the batch may be LLM slop, mass-produced output with no verification behind it.

The source is a repository named cveadvisory- under a GitHub account called programmervuln, which had published 55 “advisories” in a short span. Besides the six SQLite reports, 49 target the RAW image library libraw and the Arduino audio library ESP32-audioI2S. Those were also fabricated, except for the single report containing a real bug.

Nothing in the pipeline required verification

Here is the route the fabricated reports took from submission to NVD listing.

graph TD
    A["55 fake advisories<br/>on a GitHub repo"] --> B["MITRE submission form<br/>self-attestation only"]
    B --> C["CVE IDs assigned<br/>and published"]
    C --> D["Listed on NVD<br/>CVSS 7.5-9.8"]
    C --> E["Red Hat assessment<br/>briefly 10.0"]
    D --> F["Vulnerability scanners<br/>alert worldwide"]
    F --> G["JFrog checks against code<br/>54/55 fabricated"]
    G --> H["July 31<br/>MITRE rejects the batch"]

CVE assignment is handled by MITRE and the various CNAs (CVE Numbering Authorities). When a CNA assigns CVEs for code it doesn’t produce, there is generally no step where the assigner reproduces the report. Oracle engineer Alan Coopersmith described the structure on the oss-security mailing list. MITRE and most other CNAs that assign CVEs for third-party code operate on the honor system, he wrote, and trust that requesters have verified what they submit.

As a result, reports citing nonexistent functions were assigned IDs as-is and landed on NVD with scores from 7.5 to 9.8.
Red Hat briefly gave CVE-2026-51302 a 10.0, the maximum CVSS value. By the time JFrog re-checked during its investigation, the score had been lowered to 7.6 High. Red Hat’s page now states that its products are not affected, that the SQLite developers confirmed the CVE is fictitious, and that the assigning CNA has rejected it.

IDs listed on NVD flow straight into vulnerability scanners and SCA (software composition analysis) tools worldwide.
Since SQLite ships in browsers, phones and embedded devices everywhere, Critical alerts fired en masse, which is what produced the emails asking when the flaws would be fixed.

Speaking to The Register, Berger described the asymmetry in this structure. Generative AI has pushed the cost of producing a plausible-looking advisory to near zero. The cost of verifying one is unchanged: reading the source, building the affected version and testing the reproduction steps, for every single report. Even well-resourced defenders can’t manually validate them all.

SQLite’s official page now says “AI hallucinations”

On July 29, Hipp disclosed on the official forum that inquiries about the fictitious CVEs were coming in.
According to the thread, SuSE had run the CVEs through Claude and likewise concluded they were fabricated. Hipp went as far as writing that if you see new CVEs against SQLite, you can probably assume they are fake.

SQLite’s official vulnerabilities page was updated as well. The six reports are now listed under the “Not a bug in SQLite” classification, described as unreproducible and appearing to be AI hallucinations, with a link to JFrog’s analysis.

That page has never hidden its distrust of CVEs in general. Every historical SQLite vulnerability, it argues, presupposes that an attacker can either execute arbitrary SQL or feed the library a maliciously crafted database file, preconditions few real-world applications meet. This time, what showed up wasn’t an exaggerated precondition but a flaw that never existed.

In an August 4 reply on the forum, Hipp confirmed that MITRE never contacted the SQLite team at any point before the rejection.
No vendor check happened at assignment time, and none at rejection time either.

Timeline to rejection

Date (2026)	Event
July 27	CVE-2026-51302 and the others published on NVD
July 29	Hipp opens the forum thread and calls the CVEs fake
July 30	JFrog publishes its analysis
July 31	MITRE rejects the batch; the NVD records flip to Rejected and the news reaches oss-security
August 4	Hipp confirms on the forum that MITRE never contacted the SQLite developers

NVD’s rejection note is a single line. The record was withdrawn by its CNA because further investigation showed it was not a security issue. Four days passed between publication and rejection.
The reporting GitHub repository, meanwhile, was still public as of August 5.

NVD is sitting on a backlog of 27,000+ unprocessed entries

The fake CVEs slipped through a system whose assignment and verification layers are chronically overloaded.
According to a May 2026 report by the US Commerce Department’s Office of Inspector General, NVD’s backlog of unprocessed entries grew from about 13,000 in early June 2024 to over 27,000 by the end of 2025. The report says NIST, which operates NVD, let the backlog balloon while lacking both strategic planning and decisive action. CISA (the US cybersecurity agency) and other Authorized Data Publishers supplement the records with enrichment data, and CISA-sourced scores were attached to these fake CVEs too.

The forum discussion also touched on how projects like curl, Rust and the Linux kernel became CNAs themselves.
Becoming a CNA lets a project assign and reject CVEs for its own code, keeping low-quality third-party reports out. curl’s Daniel Stenberg has spent years pushing back against AI-generated bug reports for the same reason.

For defenders, JFrog recommends cross-checking a Critical CVE against the vendor’s own advisories, confirming the claimed fix commit actually exists in the history, and reproducing the issue in an isolated environment where possible, before jumping into patch work.
For these six, SQLite’s official vulnerabilities page lists them under “Not a bug in SQLite” and the NVD records are Rejected.