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

JFrog's security team exposed a wave of fabricated SQLite vulnerability advisories, including a fake CVE-2026-51302 that was initially rated 10.0 critical, which had flowed through NVD, CISA, and Red Hat before being debunked. The investigation found that cited functions and line numbers did not exist, and claimed patches were ghost fixes, highlighting systemic gaps in vulnerability reporting pipelines. JFrog recommends that developers implement triage workflows to filter out such AI-generated fake vulnerabilities from their build pipelines.

On July 30, 2026, JFrog's security team published something that should worry anyone whose build pipeline opens tickets automatically from a vulnerability scanner. A newly created GitHub account had submitted a batch of SQLite vulnerability advisories. NVD quickly flagged them as critical. CISA's ADP enrichment program agreed. Red Hat initially assigned one of them, CVE-2026-51302, a perfect 10.0 CVSS score. None of it was real. JFrog's investigation https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ found that the referenced functions did not exist in the SQLite versions the advisories claimed to target. Cited line numbers pointed past the end of the file. The "patched in 3.51.3" claims were ghost fixes, a diff between 3.51.2 and 3.51.3 shows zero changes to the file the advisory named. Of 55 advisories published by the same account, 54 were completely fabricated, machine-generated text designed to look like security research. When JFrog combined the advisories into one file, AI-generated content detectors lit up immediately. Red Hat quietly downgraded that 10.0 to 7.6 after the pushback. But by then the fake advisories had already flowed through the standard pipeline: MITRE form, NVD, GHSA, and from there into every enterprise scanner that syncs those feeds. If your CI setup auto-fails builds on Critical CVEs, or auto-opens Jira tickets from Dependabot or Snyk alerts, this story is about you. Here is what happened, why the system let it happen, and the triage workflow I now run on my Java pipelines so a hallucinated CVE cannot burn a week of my team's time. The details matter here, because they are the pattern you will see again. Functions that do not exist. CVE-2026-51302 9.8 Critical claimed a use-after-free in exprComputeOperands . That function did not exist in SQLite 3.41.0, the version the advisory pinned. It was added in mid-2025. The advisory also claimed sqlite3ReleaseTempReg leaves a dangling pointer, but that function just recycles register indices into an array. A use-after-free is impossible by design. Line numbers past end of file. CVE-2026-51296 7.5 High cited lines 3555 and 3575 of json.c . In SQLite 3.41.0, that entire file is 2,706 lines long. The cited lines simply do not exist. Ghost patches. CVE-2026-51303 9.8 Critical claimed a fix landed in 3.51.3. The diff between 3.51.2 and 3.51.3 contains no changes to src/expr.c at all. Proofs of concept that never execute. JFrog built SQLite in isolated Docker containers and ran every PoC under AddressSanitizer. One PoC was invalid SQL that died at the parser stage, never reaching the code it allegedly exploited. Others ran cleanly with zero memory errors. Six CVEs analyzed, six fabrications. The broader audit found 54 of 55 advisories from the account were slop, and the one remaining contained a real bug wrapped in unverified metadata. The Hacker News discussion https://news.ycombinator.com/item?id=49154332 reached 727 points and 373 comments, and the dominant concern from practitioners was the same: most organizations have no defense against this. Understanding the failure mode tells you where your own defenses need to go. No identity verification. MITRE's public CVE submission form does not verify who you are. Anyone can submit a vulnerability description and propose a CVSS score. The safety net broke in 2024. NVD used to manually analyze and enrich incoming CVEs before they got credibility. NIST effectively paused that deep analysis in February 2024 https://nvd.nist.gov/general/news/nvd-program-transition-announcement after a surge in reports, and the workload got pushed to CISA and other Authorized Data Publishers. The result is a fragmented pipeline with a large backlog. No PoC requirement. No step in the current system requires a proof of concept or a reproduction. A plausible-sounding fake advisory slides from submission to NVD to GHSA to your scanner without a single human running the exploit. That last point is the whole game. The system trusts text. LLMs generate fluent text. This will not be the last batch. You may not embed SQLite directly, but org.xerial:sqlite-jdbc is one of the most widely used JDBC drivers in the Java ecosystem, bundled into test tooling, desktop apps, and embedded services. When a Critical CVE with "sqlite" in the CPE lands in NVD, vulnerability scanners match it against every jar in your dependency tree that fits the pattern, and you get the alert. The real cost depends on your organization: This is already happening at scale elsewhere. The curl project ran a bug bounty from 2019 that produced 81 genuine security fixes and paid out over $90,000 in awards. Daniel Stenberg shut it down on February 1, 2026 https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ because AI-generated slop reports buried the maintainers. The incentive structure is now inverted: generating fake advisories is nearly free, and disproving them costs real engineer hours. I run dependency scanning on every build, and I treat every Critical alert as unverified until proven otherwise. Here is the sequence, written for a Maven-based Spring Boot pipeline, but the logic applies to Gradle or anything else. Step 1: Scan, but do not gate on raw CVSS. OWASP Dependency-Check in the Maven build gives you the base scan: <plugin <groupId org.owasp</groupId <artifactId dependency-check-maven</artifactId <version 12.1.0</version <configuration <nvdApiKey ${env.NVD API KEY}</nvdApiKey <failBuildOnCVSS 11</failBuildOnCVSS </configuration </plugin Note failBuildOnCVSS set to 11. That effectively disables build-failing on score, because CVSS alone is a terrible gate. The score measures theoretical severity, not whether the vulnerable code path exists in your usage, or whether the CVE exists at all. The scan output still gives you the full inventory, which is what you actually want. Step 2: Cross-check the CVE against a second source. NVD and GHSA frequently mirror each other, so a second opinion means going closer to the source. The OSV.dev https://osv.dev database, run by Google, is queryable by API: curl -s "https://api.osv.dev/v1/vulns/CVE-2026-51302" | jq '.summary, .modified, .affected .package.name' For a slop CVE you will often find: no advisory from the upstream project, no affected-version range that matches reality, or an entry that only echoes the original submission. Absence of upstream confirmation is not proof of fabrication, but it raises the bar before you spend engineering time. Step 3: Run the five-minute slop check on the advisory itself. This is the highest-leverage habit, and it comes straight from JFrog's red flags: Step 4: Confirm the vulnerable code is even in your tree. For a Java service, check whether the flagged dependency is in your runtime path at all, and at what version: mvn dependency:tree -Dincludes=org.xerial:sqlite-jdbc A jar that appears only in test scope, or transitively through tooling you do not ship, changes the priority completely. Most scanner noise in Java pipelines is scope noise before it is anything else. Step 5: Document the verdict, either way. Whether the CVE is real or fabricated, write down what you checked and link the evidence: the advisory, the source check, the decision. When the compliance audit comes, "we verified the cited function does not exist in the pinned version, here is the link" is a defensible exception record. "We ignored it" is not. An append-only triage log, one row per CVE, costs minutes and saves repeated investigations when the same alert re-fires next week. Since I write a lot about building AI agents, one more warning. If you have wired an LLM into your alert pipeline to summarize or auto-triage CVEs, a fabricated advisory is close to a worst-case input. The model will read fluent, technically-detailed text describing a plausible use-after-free, and it will happily draft a remediation plan for it. The failure is invisible because the output reads exactly like a correct triage. The defense is structural, not prompt-based: never let the agent close the loop on Critical severity alone. Require the machine-checkable evidence as an input, does the function exist, do the line numbers resolve, is there a vendor advisory, and make the agent cite that evidence in its output. If the evidence step cannot be automated yet, the agent's job is to prepare the checklist for a human, not to decide. If you are setting up dependency scanning for a Java service right now: None of this means abandoning CVE monitoring. It means treating vulnerability feeds as untrusted input, which, as of this month, is what they are. Have you hit a fabricated or wildly-inapplicable CVE in your pipeline yet? How did your team handle it, and did your process survive contact with it? I would genuinely like to know, because the collective playbook here is still being written. I write about Java, Spring Boot, and AI engineering every week, usually from the middle of problems exactly like this one. Subscribe, it's free, and it's the best way to catch the next piece, where I plan to wire this checklist into an automated CI gate.