Devlery
Blog/AI

Six AI-Invented SQLite CVEs Scored 9.8 on NVD, Then Got Withdrawn

JFrog tried to reproduce six SQLite CVEs and none of them held up. The functions they blamed did not exist in those versions, and the proof-of-concept code never crashed. MITRE rejected all six on July 31, but the GitHub Advisory DB still shows 9.8 Critical.

Six AI-Invented SQLite CVEs Scored 9.8 on NVD, Then Got Withdrawn
AI 요약
  • What happened: six SQLite CVEs (CVSS 9.8 down to 7.5) landed in the US government vulnerability database NVD and were withdrawn four days later. The functions they named did not exist in the affected versions.
    • JFrog reproduced nothing: not one PoC crashed, and one advisory cited line 3555 of json.c, a file that is 2,706 lines long
    • The SQLite project's official CVE page now reads "These are unreproducible. They appear to be AI hallucinations."
  • Scale: the same GitHub account published 55 advisories and 54 were fabricated. Beyond SQLite, it also targeted libraw and ESP32-audioI2S.
  • Why it got through: no step in CVE assignment or publication requires a PoC or a reproduction. NVD effectively stopped deep analysis in 2024 and its unenriched backlog passed 27,000 records.
  • Not over yet: NVD marked the records Rejected, but GHSA-vrg3-8p22-cwh8 in the GitHub Advisory DB was still Critical 9.8, Unreviewed as of August 3. Scanners that read that database keep firing.

Six SQLite vulnerabilities were published at the highest severity in public security databases and pulled four days later. The functions the reports blamed were not in those versions of the code.

A CVE is the global serial number attached to a software vulnerability. Once a number exists, corporate scanners walk dependency manifests, match it, and open work. That is the whole point of the system, and it is also why a single bad record generates hours of labor across thousands of organizations.

The six records were submitted to MITRE on July 27, 2026 and published to NVD, the US government vulnerability database. The top CVSS score was 9.8, and CISA's enrichment program (ADP) attached scoring vectors. JFrog security researcher Afek Berger published a reproduction analysis on July 30. MITRE withdrew all six the next day.

July 27

Advisories from a new GitHub repository reach MITRE and get published to NVD. CISA ADP assigns CVSS vectors

July 30

JFrog publishes its failed-reproduction analysis. Red Hat lowers its score from 10.0 to 7.6

July 31

MITRE rejects all six. Reason: "further investigation showed that it was not a security issue"

Line 3,555 of a 2,706-line file

What JFrog did was simple: follow the reports literally. Clone the official sqlite/sqlite repository, check out the three tags named in the advisories (version-3.41.0, version-3.51.2, version-3.51.3), build with AddressSanitizer enabled to catch memory errors, and run the attached exploit code.

Nothing crashed. Some of the proof-of-concept code failed at the SQL parser stage, never reaching the code path it claimed to break.

All six advisories described a use-after-free, a bug where a program reads memory it has already released. Real ones score high because a remote attacker can leak data or execute code through them. The problem was where the reports said the bugs lived.

What the advisory claimedWhat JFrog found
CVE-2026-51302: use-after-free in exprComputeOperands()That function is not in SQLite 3.41. It was added in mid-2025
CVE-2026-51297: reached via jsonBlobEdit()Function does not exist in 3.41.0
CVE-2026-51296: json.c lines 3555 and 3575The file is 2,706 lines total
CVE-2026-51300: use-after-free at specific linesThose lines are comments or unrelated allocation calls
CVE-2026-51303: fixed in 3.51.3That release diff contains no change to src/expr.c

JFrog also noted that concatenating the advisories into one file and running it through the AI detector GPTZero produces an AI-generated warning. The publisher was programmervuln/cveadvisory-, a GitHub repository created that same month, and 54 of the 55 advisories from that account followed the same pattern. The one real bug still had unverified metadata. The targets were not limited to SQLite either: the image library libraw and the embedded audio library ESP32-audioI2S got the same treatment.

Same CVE number, four different answers

The withdrawal did not settle things. Four organizations handling the same CVE numbers currently show different information.

  • NVD: all six Rejected. The text reads "this record was withdrawn by its CNA. Further investigation showed that it was not a security issue." Scores, CWE classifications, and reference links were removed with it.
  • SQLite project: the official CVE page at sqlite.org/cves.html groups all six into one row marked "not a bug in SQLite," with the note "these are unreproducible. They appear to be AI hallucinations. See the analysis at JFrog.com."
  • Red Hat: initially scored CVE-2026-51302 at 10.0 Critical, later lowered it to 7.6 High.
  • GitHub Advisory DB: as checked on August 3, still Critical 9.8, status Unreviewed.

The GitHub Advisory Database page for GHSA-vrg3-8p22-cwh8. CVE-2026-51302, already withdrawn by NVD, still shows Critical severity, Unreviewed status, and CVSS 9.8, with an empty affected-packages section

That single screen contains most of the warning signs JFrog listed. The affected package reads "No package listed", and both the affected and patched versions are "Unknown." None of the three reference links point to a maintainer commit or pull request, and one of them points back at the repository that filed the advisory. The score on the right still says 9.8.

Most scanners read NVD and the GitHub Advisory DB together. When one side withdraws and the other does not, the alerts keep coming.

Nothing in the process asks you to reproduce it

The new part of this incident is not the person who wrote the fake reports. It is that the pipeline has no place where they would be caught. JFrog put it this way:

"Since no stage in today's process requires a PoC or bug reproduction, plausible-sounding fake advisories can pass straight through the pipeline and reach GitHub Security Advisories, downstream databases, and enterprise scanners."

Berger described the cost asymmetry to The Register: generative AI has driven the effort of producing a plausible advisory close to zero, while the effort of verifying one has not moved.

Verification capacity has actually shrunk. NVD effectively stopped deep-analyzing individual CVEs in February 2024, and its unenriched backlog crossed 27,000 records by the end of 2025. CVE submissions grew 263% between 2020 and 2025, and Q1 2026 ran roughly 33% above the same quarter a year earlier. NIST enriched about 42,000 records in 2025, 45% more than its previous peak, and still fell behind the inflow.

So on April 15, 2026 NIST changed its policy. It now analyzes immediately only those CVEs that appear in CISA's known-exploited catalog (KEV), run in federal software, or fall under the critical-software definition from Executive Order 14028. Everything else is "lowest priority," and unenriched CVEs from before March 1, 2026 were moved wholesale to "Not Scheduled." These six arrived three months into that policy.

This runs opposite to the Cisco Antares result we covered earlier, where a 1B model localized real vulnerabilities for about a dollar apiece and beat a 753B model at it. Finding bugs with AI got cheap; inventing them with AI got cheap first. When both costs fall toward zero, reproduction is the only bottleneck left.

The four warning signs JFrog listed are things a human can check in five minutes.

No maintainer confirmation

The project's own security page has no matching entry

No commit link

References contain no fix commit hash or pull request

Contradictory metadata

Empty affected package (CPE), or version ranges that conflict

Code that is not there

Functions absent from that version, line numbers past the end of the file

Teams that have handed vulnerability triage to a coding agent carry an extra risk here. An agent that cannot find a named function may not stop and report that; it may write a plausible-looking patch instead. A human reading the same advisory would have ended at "this function does not exist."

If your SCA scanner raised a Critical on SQLite 3.41 or the 3.51 line last week, checking the CVE number against both NVD and sqlite.org/cves.html before you open a ticket closes out all six of these. NVD showing Rejected is not sufficient on its own, because scanners that also read the GitHub Advisory DB still report 9.8, and acting on scanner output alone puts an engineer on a vulnerability that does not exist. Given that another batch is likely, adding one line to your triage rules, do not open a ticket on a Critical from a new account when the references contain no maintainer commit link, is cheaper than reproducing every report by hand.