Fabricated SQLite CVEs cleared NVD, CISA ADP and Red Hat before anyone ran the code

Every defect JFrog documented is checkable against a source tree in about ten minutes. The named function has to exist in the pinned version: CVE-2026-51302 claimed a use-after-free in `exprComputeOperands()`, which was not in SQLite 3.41.0 and only appeared in mid-2025 ^[5]. The cited line has to be inside the file: CVE-2026-51296 pointed at lines 3555 and 3575 of `json.c`, which stops at 2,706 lines in that release ^[6], an overshoot of 849 ^[16]. The patch has to touch the file it claims to fix: CVE-2026-51303 put the fix in 3.51.3, and the diff from 3.51.2 leaves `src/expr.c` untouched ^[7]. None of that needs a vulnerability researcher. It needs a checkout and the version string from the advisory.

Proving the negative properly was more expensive. JFrog built SQLite in isolated Docker containers and ran every proof of concept under AddressSanitizer; one was invalid SQL that died in the parser, and the rest executed with no memory errors at all ^[8]. That is hours per advisory. The submitter's side of the ledger is a MITRE form that does not verify identity and lets anyone propose a CVSS score ^[9], with no step in the chain requiring a reproduction ^[11]. The asymmetry got worse in February 2024, when NIST paused NVD's deep analysis after a surge in reports and pushed enrichment onto CISA and other Authorized Data Publishers, leaving a backlog ^[10].

The reason this reaches Java teams that have never compiled SQLite is CPE matching. `org.xerial:sqlite-jdbc` is one of the most widely used JDBC drivers in the ecosystem, bundled into test tooling and desktop apps ^[13], so a Critical carrying sqlite in its CPE fans out across dependency trees that contain a jar and no C at all.

Style detection is the wrong place to put the gate. The AI content detectors only fired once JFrog concatenated all 55 advisories into a single file ^[15]. That is a corpus-level signal, and a lone advisory arriving in a nightly feed sync does not carry it. The check that works is structural: compare the advisory's own claims against the code it names.

The rate matters as much as the mechanism. Fifty-four of 55 advisories from that account were fabricated, and the survivor was a real bug wrapped in unverified metadata ^[4], a 98 percent fabrication rate with no clean examples in the set ^[17]. A filter strict enough to stop the fakes would also have held the true one for verification, which is the right outcome rather than a false positive.

Red Hat's correction, 10.0 down to 7.6 ^[3], is a 2.4 point move ^[18] that still leaves a High score attached to a defect nobody has demonstrated. The Hacker News thread ran to 727 points and 373 comments, and the recurring practitioner complaint was that they have no defense against this ^[14]. The defense is a gate between the feed and the tracker, running the three checks above.