54 of 55 CVEs Were AI-Invented. One Scored a 10.0

JFrog found 54 of 55 CVEs from one GitHub account were AI-fabricated. One hit a 10.0. The pipeline never asked for a working exploit.

A single obscure GitHub account published 55 vulnerability advisories, and JFrog Security Research determined that 54 of them were entirely AI-fabricated. The fakes still reached the National Vulnerability Database with CISA enrichment, and Red Hat briefly stamped one of them a perfect 10.0, because no checkpoint anywhere in the process required a working exploit before the rating went out.

Sources: JFrog: SQLite Critical CVEs or LLM Slop?

That last clause is the whole story, and it is also the reason this post exists. We build TLM Forge, a discipline layer that blocks AI-written changes from shipping until an adversarial gate clears, so we have a commercial stake in the argument that plausibility is not verification. The CVE incident is that argument playing out in public infrastructure rather than in a code review, and the mechanism is identical: a system trusted the way an output looked instead of testing whether it was true.

What JFrog actually found

On July 30, 2026, JFrog published its analysis of a repository under the account programmervuln/cveadvisory-, which had filed dozens of advisories in a short window in late July. Six of them targeted SQLite, one of the most widely deployed and heavily audited databases in the world, with CVSS scores ranging from 9.8 down to 7.5. JFrog tested each one. None reproduced. When the full set was audited, 54 advisories were completely fabricated and exactly one contained a genuine bug, that one sitting among the non-SQLite reports rather than the SQLite batch.

Sources: JFrog: SQLite Critical CVEs or LLM Slop?, SC Media: Bogus SQLite vulnerabilities highlight flaws in CVE pipeline

The tells were the kind an AI model produces and a hurried human misses. One use-after-free advisory relied on a function that did not exist in the affected SQLite version. Another, CVE-2026-51296, cited lines 3555 and 3575 of json.c as the vulnerable code, in a file that is only 2,706 lines long. The proof-of-concept scripts, where they were provided at all, executed a valid query and returned clean, with no memory leak and no crash. Every surface detail looked like a real advisory. Nothing underneath it was real.

Sources: JFrog: SQLite Critical CVEs or LLM Slop?, The Register: AI slop pollutes the CVE pipeline

How a fabrication reached "Critical"

The advisories did not sneak in through a side door. They rode the front door of the vulnerability supply chain: a CVE ID gets reserved, the advisory flows into the NVD, CISA enrichment adds context, and downstream scanners and vendors pick it up. At each of those hops the artifact was treated as trustworthy because it was well-formatted and internally consistent. CISA enrichment fills gaps in the record. It does not re-derive the vulnerability from scratch.

Sources: SC Media: Bogus SQLite vulnerabilities highlight flaws in CVE pipeline

The timing made it worse. NIST's manual analysis of CVEs slowed dramatically in 2024 under a surge of submissions and operational strain, and the backlog of unprocessed CVEs grew from more than 17,000 in late 2024 to more than 27,000 by the end of 2025, per a Department of Commerce Inspector General report. A pipeline already drowning in real submissions has no spare capacity to reproduce each one, which is exactly the condition under which cheap, high-volume fabrications do the most damage.

Sources: The Register: AI slop pollutes the CVE pipeline

The scoring made the gap visible. For CVE-2026-51302, whose advisory pointed at a function that did not exist in the affected version, the NVD carried a 9.8 while Red Hat initially assigned the same fabricated flaw a maximum 10.0 before quietly walking it back to 7.6. Two separate authorities scored a bug that did not exist, and the ratings they produced for it spanned 2.4 points, from 7.6 to a perfect 10.0. A number computed from a fictional attack vector is precise, confident, and meaningless, and it propagates to every dashboard that ingests the feed.

Sources: JFrog: SQLite Critical CVEs or LLM Slop?, The Register: AI slop pollutes the CVE pipeline

JFrog stated the root cause in one sentence. "Because no step in today's system actually requires a proof-of-concept or bug reproduction, a plausible-sounding fake advisory can slide right through the pipeline." MITRE eventually rejected the entire repository of vaporous vulnerabilities, but the rejection came after the ratings had already been published, indexed, and enriched. The correction was slower than the pollution.

Sources: JFrog: SQLite Critical CVEs or LLM Slop?, The Register: AI slop pollutes the CVE pipeline

Plausibility is not verification

This is the specific failure mode that large language models are built to exploit, and they exploit it without any intent to deceive. A model that generates a vulnerability advisory produces correct CVSS vector strings, a well-formed function reference, a believable line number, and a PoC that parses. Those are surface properties of a real advisory, and a model is very good at surface properties. The one property it cannot fake is the one nobody checked: that running the PoC against the target actually causes the described failure.

The reason the fakes worked is that the entire vulnerability pipeline is a chain of looks-right gates. Formatting looks right, so the advisory advances. A function name looks plausible, so a reviewer assumes it exists. A CVSS score looks carefully computed, so a vendor mirrors it. Each gate checks the shape of the artifact and passes it to the next gate, which checks a different aspect of the shape. Reproduction is the only gate that checks substance, and it was optional at every step.

The same gap sits inside your AI code review

Swap "advisory" for "pull request" and the story is the one every engineering team is now living. An AI coding agent produces a diff with correct syntax, sensible variable names, a plausible library call, and a test that passes. Those are surface properties of correct code, and the model is excellent at them. Whether the change actually does what the ticket asked, under the inputs that matter, is a substance question, and most review processes check it about as rigorously as the CVE pipeline checked those PoCs.

The non-existent SQLite function has a direct analogue in code you merge every week. Models routinely invent API methods, config keys, and library functions that read as real and do not exist, a pattern documented in /blog/ai-hallucinated-apis. A reviewer skimming for whether the code looks right will approve a call to a method that was never defined, exactly as a triager approved a line number past the end of the file. The forgery is obvious the moment you execute it and invisible the moment you only read it.

Verification also has to persist. The reason a fake advisory keeps causing damage is that the evidence trail, or its absence, is not carried forward: the next scanner, the next vendor, the next on-call engineer sees the score and not the fact that nobody reproduced it. Teams reviewing AI output hit the same problem across sessions, which is part of why a private, persistent memory layer like MemX exists, to keep the record of what was actually checked attached to the work instead of evaporating when the chat window closes.

What an evidence-based gate looks like

The fix is not more reviewers looking harder at the same surface. It is a mandatory checkpoint that refuses to pass anything on plausibility alone. In vulnerability handling, that means requiring a reproduction, a commit hash, or a linked pull request before an advisory earns a score, which is close to the verification checklist JFrog recommended in response. In AI-assisted engineering, it is the same principle turned into a merge gate: the change reproduces the intended behavior under test, or it does not ship.

Sources: SC Media: Bogus SQLite vulnerabilities highlight flaws in CVE pipeline

That is precisely what TLM Forge enforces. Its convergence gate blocks a diff from shipping while any critical finding is open, and its review runs adversarially, with agents that did not write the code trying to break it rather than confirm it reads well. Red-teaming your AI code is the same instinct the CVE story argues for: assume the artifact is a plausible fake until an independent, evidence-based check proves otherwise. A model can generate a convincing advisory or a convincing diff. It cannot generate a reproduction of a bug that is not there.

The honest boundary matters here. A gate like this does not make AI output worse or slower to write, and it does not catch every class of error. What it catches is the specific failure the CVE incident demonstrates: output that is correct in form and false in substance, sliding through because every check was a looks-right check. The 54 fabricated advisories cleared a pipeline run by security professionals. The lesson is not that those people were careless. It is that a process built entirely on plausibility gates will pass plausible fabrications every time, and AI has made plausible fabrications free to produce at scale.

One account produced 54 fake vulnerabilities in days, and a public system built by careful engineers rated them, enriched them, and shipped them before anyone reproduced a single one. Any team pointing an AI coding agent at production is running a smaller version of that same pipeline. The question worth asking before the next merge is not whether the change looks right. It is whether anything in your process would have caught a line number pointing past the end of the file.