Six Critical CVEs Hit SQLite. All Six Were Hallucinated.

TL;DR

On July 27, six new CVEs landed against SQLite, two of them scored 9.8 Critical. They flowed through the usual pipeline: MITRE issued the IDs, the National Vulnerability Database picked them up, and per JFrog Security Research, CISA's ADP program agreed with the critical rating. Then someone actually read them. The functions they described did not exist in the versions they targeted. One advisory placed a use-after-free at line 3575 of a file that is 2706 lines long. The proof-of-concept payloads crashed nothing. All six were withdrawn by July 31, and SQLite's official vulnerabilities page now lists them under a single verdict: "They appear to be AI hallucinations."

What was published

The six records are CVE-2026-51296, 51297, 51300, 51302, 51303, and 51304, all filed against SQLite 3.41 and adjacent releases. JFrog's writeup lists the severities they carried when published.

SQLite is not an obscure target. It ships in every Android phone, every iPhone, every browser, and most of the embedded devices in your house. A 9.8 against it is the kind of thing that reroutes an on-call rotation.

How JFrog took them apart

The tell was not subtle once anyone looked at the source. CVE-2026-51302 described a use-after-free in exprComputeOperands() in SQLite 3.41. That function did not exist in 3.41; it was added in the middle of 2025. CVE-2026-51303 claimed patches to ExprListDelete() that JFrog describes as entirely fabricated.

CVE-2026-51296 is the one worth framing. It reported a use-after-free in the JSON module, with the object freed at line 3555 of src/json.c and reused at line 3575. That file is 2706 lines long. The bug was not merely unreproducible; it was located past the end of the file.

JFrog ran the proof-of-concept payloads. Nothing crashed. They ran the advisory text through GPTZero, which flagged it as AI-generated. And none of the six appeared on SQLite's own advisory page, which is the first place a real SQLite bug shows up.

It was not six. It was fifty-four.

The advisories traced to a newly created GitHub repository, programmervuln/cveadvisory-. JFrog audited the account's full output.

Fifty-four of fifty-five were completely fabricated. The single exception contained a real bug wrapped in unverified CVE metadata, which is the security equivalent of getting one answer right on the exam and putting the wrong name on the paper.

Why the pipeline let it through

Here is the part that should bother you more than the fake bugs. Nothing in the chain between "a stranger writes a paragraph" and "your scanner turns red" performs verification.

The CVE system is closer to a post office than a laboratory. It will assign your package a tracking number and route it worldwide without ever asking what is inside. The number means "this claim has an identifier," not "this claim is true," and every downstream tool that treats a CVE ID as a verdict is making an inference the system never promised to support.

That was survivable when writing a convincing vulnerability report required understanding the code. Generating fifty-five plausible advisories with real function names, real file paths, and confident line numbers is now an afternoon of prompting. The economics of the attack changed; the verification step did not.

What the downstream cleanup looked like

The NVD records for all six now read: "This record was withdrawn by its CNA. Further investigation showed that it was not a security issue." Published July 27, rejected July 31. Every reference link has been stripped from the records.

Red Hat scored CVE-2026-51302 at 7.6 before the withdrawal and now states that SQLite upstream have confirmed the CVE as fictitious, that it does not affect Red Hat products, and that "customers may safely treat scanner findings for this CVE as a false positive." That is a sentence a vendor has to write, publish, and defend, for a bug that never existed.

SQLite has been saying this for years

The SQLite project's vulnerabilities page did not need updating to accommodate this event, because its thesis already covered it. The page describes CVEs as "a low-quality source of information about bugs in SQLite," notes that the developers do not track CVEs at all, and states plainly that "grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims."

That was written about humans farming reputation. It generalizes without modification to a model farming tokens. This week the incident file finally caught up with the opinion.

What to actually do

JFrog's guidance is short and worth adopting as policy rather than as a one-time reaction:

• Do not treat a newly published CVE from an unknown or unvalidated reporter as actionable on arrival.
• Check whether the severity score matches the described mechanism before it enters your queue.
• Reproduce the issue with the provided proof of concept in a safe environment whenever one is supplied.

Practically: when a Critical lands against a dependency, spend ninety seconds checking whether the cited function exists in the version you ship. Two of these six died on that check alone. If the upstream project maintains its own advisory page, as SQLite does, that page outranks the database.

The failure mode here is not that you patch a fake bug, since there is nothing to patch. It is that you burn a real incident response on a fiction, and that the next real 9.8 arrives to a team that has learned to shrug.

Key Takeaways

• Six SQLite CVEs published July 27 (51296, 51297, 51300, 51302, 51303, 51304), two rated 9.8 Critical, were withdrawn by July 31 as "not a security issue."
• SQLite's official vulnerabilities page now lists all six as "not a bug in SQLite" and states they "appear to be AI hallucinations."
• JFrog found cited functions that did not exist in the targeted versions, and a use-after-free reported at line 3575 of a 2706-line file.
• Of 55 advisories from the same GitHub account, 54 were completely fabricated; the one exception was a real bug with unverified metadata.
• Per JFrog, NVD rated them critical and CISA's ADP concurred, meaning the slop reached scanners worldwide with no reproduction attempt anywhere in the chain.
• Red Hat had to publish an advisory telling customers to treat scanner findings for CVE-2026-51302 as a false positive.

Sources: JFrog Security Research, SQLite Vulnerabilities page, NVD CVE-2026-51302, NVD CVE-2026-51296, Red Hat CVE-2026-51302