AI Security Series · Part 16
A few days ago we covered a genuinely good story: Google fixed more than a thousand Chrome security bugs in a single month, many surfaced by AI, including a real sandbox escape that had hidden in the codebase for 13 years. AI finding real bugs at scale. That's act one.
Here's act two. Last week, six "critical" SQLite vulnerabilities — CVSS scores from 7.5 all the way to 9.8 — appeared in the National Vulnerability Database, complete with CISA-supplied severity enrichment. Enterprise scanners started flagging them. Security teams started asking whether they needed to patch.
They didn't. The vulnerabilities weren't real. According to JFrog's teardown, all six appear to be AI-generated slop — convincing, well-formatted, completely fabricated.
How fake looks real
What makes JFrog's analysis damning is how it fell apart under the lightest technical pressure:
- The "patch" doesn't exist. For CVE-2026-51303, the advisory claimed a fix landed between SQLite 3.51.2 and 3.51.3. JFrog: "a diff between 3.51.2 and 3.51.3 shows absolutely no changes to
src/expr.c. The 'patch' was entirely fabricated." - The proof-of-concept doesn't run. The PoC "is invalid SQL and fails at the parser stage, never actually hitting the execution logic." It doesn't just fail to exploit anything — it doesn't even parse.
- The code being described isn't there. The advisories referenced functions and source locations that don't exist in the affected versions.
- The vendor never heard of them. None of the six appear on SQLite's own advisory list at sqlite.org.
- The text tests as machine-written. Run through GPTZero, "all advisories in this repo seem AI generated."
Every one of these is a check that takes minutes. Together they say the same thing: nobody performed them before these landed in the world's most-trusted vulnerability feed with critical severity scores.
One honest note on attribution: JFrog's tooling flags the text as AI-generated, but who created these and why is unknown — they came from a new, obscure GitHub repository. We're not asserting intent. The point isn't the culprit; it's the pipeline.
The real vulnerability is the pipeline
This is the part that should worry anyone who consumes vulnerability data — which is everyone. The CVE reporting supply chain has no verification layer that can tell a real bug from a fabricated one. As the reporting on this made painfully clear: no step in the current system actually requires a working proof-of-concept or a reproduction. A plausible-sounding advisory can slide straight through into the NVD, pick up a CISA-enriched CVSS score, propagate to GitHub advisories, downstream databases, and enterprise scanners — before anyone checks whether the bug is real.
To be clear about where the failure sits: this is a systemic pipeline gap, not CISA or NVD acting carelessly. The enrichment step does what it's designed to do; it just isn't designed to catch fabrication. And in the age of LLMs, fabrication is now cheap, fast, and formatted to look exactly like the real thing.
Tie the two acts together: the tools that found 1,072 real Chrome bugs and the tools that invented 6 fake SQLite ones are the same class of tools. Part 11 of this series argued the tools got brilliant while the bugs stayed boring. The update is that the reports got brilliant too — and a brilliant-looking false report is its own kind of attack. Trust in the vulnerability supply chain has quietly become an attack surface.
What to actually do
You can't patch a bug that doesn't exist, but you can stop wasting a sprint chasing one. Before you treat a scary new CVE as real, run the same four checks that took JFrog minutes:
- Vendor corroboration first. Does the actual maintainer list it? If a critical SQLite CVE isn't on sqlite.org, that's a five-minute red flag worth more than any CVSS score.
- Follow the references to real code. Is there a genuine commit hash or pull request? Does the cited source file/function actually exist in that version? A referenced "patch" with a zero-line diff is a fabrication tell.
- Does the PoC run? Not "does it exploit" — does it even execute past the parser? An invalid PoC that can't run is not evidence of anything.
- Sanity-check the prose. AI-detection is imperfect, but a batch of advisories from an unknown source that all trip AI-content detectors deserves scrutiny before it drives your patch cycle.
The uncomfortable takeaway of this series keeps rhyming: AI is a force multiplier, and it doesn't care which side it multiplies. It found a 13-year-old bug that humans missed. It also manufactured six critical vulnerabilities that never existed and walked them into the NVD. Both happened the same week. The skill that matters now isn't running the tools — everyone runs the tools — it's verifying what comes out of them.
Sources: JFrog Security Research (original teardown), The Register, and LWN.
Drowning in scanner alerts and not sure which are real? Talk to Sid Techno — we help teams triage vulnerability noise and focus on the threats that actually reproduce.