A 9.8 Critical CVE That Never Existed: How to Filter Fake Vulnerabilities Out of Your Java Pipeline

On July 30, 2026, JFrog's security team detected a suspicious batch of SQLite vulnerability advisories submitted from a newly created GitHub account. The National Vulnerability Database (NVD) and the Cybersecurity and Infrastructure Security Agency (CISA) quickly flagged these advisories as critical, assigning a perfect 10.0 CVSS score to CVE-2026-51302.

However, JFrog found that none of these advisories were real. The referenced functions did not exist in the SQLite versions they claimed to target, and the cited line numbers pointed past the end of the file. Of the 55 advisories published by the same account, 54 were fabricated, machine-generated text designed to look like security research.

Red Hat initially assigned the highest possible CVSS score to one of these advisories but later downgraded it to 7.6 after pushback. This fabricated vulnerability had already propagated through the standard pipeline, affecting multiple enterprise scanners. The fabricated advisories contained non-existent functions, incorrect line numbers, and ghost patches.

The system allowed these fabricated vulnerabilities to pass through because there is no identity verification for CVE submissions, and no proof of concept (PoC) requirement in the current system. Java teams, in particular, should be concerned as they often use SQLite through the org.xerial:sqlite-jdbc JDBC driver. When a Critical CVE with "sqlite" in the Common Platform Enumeration (CPE) lands in vulnerability scanners, it triggers alerts, potentially causing unnecessary investigations and builds to fail.

To mitigate this risk, a triage workflow for Java pipelines should be implemented. First, scan for vulnerabilities but do not gate on raw CVSS scores. Then, manually verify the advisories before taking any action.