A newly created GitHub repository has published a series of advisory notices on alleged critical vulnerabilities in SQLite. NVD assigned CVSS scores up to 9.8, and CISA’s ADP confirmed the severity. When JFrog researchers went to verify, the functions cited didn’t exist in the indicated versions, the proof-of-concept examples caused no crashes, and the supposed patches were nonexistent. The advisory notices, passed through an AI content detector, came back as language model-generated.

Why this matters to you. The automated systems that classify vulnerabilities processed these false alarms as if they were real. If your CI/CD pipeline includes automated checks on CVEs in your dependencies, you may have received alerts on bugs that don’t exist. Critical security infrastructure ingests content without verifying it, and that content can now be generated by an LLM at nearly zero cost.

This concerns anyone using AI agents to automate security analysis. The same ease with which a model writes a credible advisory on first reading is the ease with which it produces any plausible but wrong output. A verification step, even a quick one, costs less than a false alarm that triggers an incident response plan for a threat that never existed.

In detail

The repository programmervuln/cveadvisory- published around twenty advisory notices on SQLite vulnerabilities in early August, plus another fifty reports that JFrog believes were similarly LLM-generated. The National Vulnerability Database (NVD) registered six of these CVEs with high scores: two at 9.8 (critical), one at 9.1, three between 7.5 and 8.8. CISA’s Automated Decision Plugin (ADP) validated the severity ratings.

JFrog followed a rigorous protocol to verify each report: cloned the official SQLite repository, checked out the cited versions (3.41.0, 3.51.2, 3.51.3), compiled in isolated containers, and tested proof-of-concept samples under AddressSanitizer to detect memory violations.

The results are unequivocal. CVE-2026-51302 (9.8 critical) cites the exprComputeOperands() function as the site of a use-after-free, but that function didn’t exist in SQLite 3.41: it was introduced in 2025. The sqlite3ReleaseTempReg() function mentioned as the cause of the dangling pointer doesn’t allocate heap memory: it recycles register indices in an array, making a UAF impossible by design.

CVE-2026-51303 (9.8 critical) describes a fix in version 3.51.3 that simply doesn’t exist. The diff between 3.51.2 and 3.51.3 shows no modifications to src/expr.c. The associated PoC is invalid SQL and gets rejected by the parser before reaching execution logic.

CVE-2026-51300 (9.1 critical) cites specific line numbers in expr.c that correspond to a comment and a memory allocation call, with no connection to the deletion logic described. The PoC, when run as valid SQL, returns the expected output with no memory leak.

Two signals confirm generative origin. JFrog passed the advisory notices through GPTZero, which classified them as AI-generated content. And combining all advisory notices into a single file, AI content detectors trigger warnings immediately. The repository appears to be an experiment, or coordinated attack, where someone uses an LLM to produce technically plausible advisory notices at first glance and submits them to vulnerability tracking systems.

What changes. The vulnerability trust pipeline works like this: someone publishes an advisory, NVD registers it, CISA evaluates it, and dependency scanning tools propagate it to developers. Until now, the bottleneck was the supply of human-written advisory notices. With an LLM, the bottleneck disappears: you can generate hundreds of credible CVEs on a first reading in an afternoon.

Red Hat initially assigned one of these CVEs a score of 10.0, then lowered it to 7.6. Even professional triage teams, faced with a well-constructed advisory, struggle to distinguish fact from fiction without diving into the code.

What remains open. We don’t know who’s behind the repository, or whether the goal was to test the systems, create noise to cover something else, or prove it can be done. JFrog analyzed six CVEs in detail: the other 50+ reports from the same repo remain to be verified one by one. And we don’t know how many automated security tools have already alerted developers to these false CVEs, nor how many teams have redirected resources to respond to nonexistent threats.