Introduction

Over the past few days, a newly created GitHub account published a batch of SQLite vulnerability advisories alongside 50+ other projects and called them critical. The US National Vulnerability Database flagged several as critical, and CISA's Authorized Data Publishers agreed. Then JFrog's security researchers checked the claims and found they fell apart: functions named in the advisories never existed in the cited versions, the PoC payloads did not crash anything, and SQLite's own advisory page lists none of these CVEs. This is the AI slop CVE problem, and it is now hitting the database at the center of the entire vulnerability ecosystem.

What Actually Happened

The story starts with a GitHub account called programmervuln/cveadvisory-, which published a batch of SQLite advisories (plus 50+ other CVEs that JFrog believes are also largely fabricated). NVD quickly flagged these as critical, and CISA agreed. When JFrog dug in, four things stood out:

1. The cited code did not exist in those versions, or referenced unrelated logic.
2. The PoC payloads, when tested, did not work and did not trigger any crash.
3. None of the CVEs appear on SQLite's official advisory page, which is the gold standard for tracking real vulnerabilities.
4. The advisories read as AI-generated when run through GPTZero detection.

A broader audit of 55 advisories from the same account found 54 were completely fabricated. One contained a real bug wrapped in unverified CVE metadata.

The scores are already moving. CVE-2026-51302 was initially assigned a 10.0 Critical severity by Red Hat; days later, the score was downgraded to 7.6 High.

The Audit: Six "Critical" SQLite CVEs

JFrog published its verification in a CVE-by-CVE table. The short version: every single claim fails.

CVE	Reported flaw	CVSS	Audit finding
CVE-2026-51302	UAF in exprComputeOperands()	9.8	Function did not exist in SQLite 3.41; added mid-2025
CVE-2026-51303	UAF in ExprListDelete() back-references	9.8	Diff between 3.51.2 and 3.51.3 shows zero changes to expr.c; the "patch" was fabricated
CVE-2026-51300	UAF in sqlite3ExprDelete()	9.1	Cited lines 1012 and 1026 are a comment and an allocation call
CVE-2026-51297	UAF via jsonBlobEdit()	8.8	jsonBlobEdit() was not present in 3.41.0; it shipped later with JSONB
CVE-2026-51296	UAF in jsonRemoveFunc	7.5	json.c is 2706 lines in 3.41.0; cited lines 3555 and 3575 do not exist
CVE-2026-51304	UAF via pOrderBy->nExpr post-free	7.5	Reported signature does not exist; SQLite nulls the pointer right after delete

How JFrog Verified the Claims

The verification workflow is worth copying for any suspicious CVE:

• Source inspection. Cloned the official sqlite/sqlite repository and checked out the target tags: version-3.41.0, version-3.51.2, and version-3.51.3. Compared the reported mechanics against the actual source.
• Clean builds. Compiled official SQLite releases in isolated Docker containers to avoid environmental contamination.
• PoC execution. Fed each advisory's PoC SQL verbatim into ASan-instrumented builds to catch memory bugs.
• Metadata audit. Cross-checked CPE patterns and metadata across NVD and GHSA feeds.

One example shows how shallow the fake reports are. The advisory claimed sqlite3ReleaseTempReg() leaves a dangling pointer in regFree1 that is later dereferenced by exprComputeOperands(). The real function, from SQLite 3.41.0, looks like this:

It recycles register indices into an array for reuse. There is no heap deallocation, so a use-after-free is impossible by design. And exprComputeOperands() did not exist in 3.41 at all; it was added in the middle of 2025. The PoC ran without a crash because the bug does not exist.

Why Fake CVEs Slip Through

The submission process is the weak link. MITRE's public form has no real identity verification, so virtually anyone can submit a vulnerability description and propose a CVSS score. Historically NIST acted as a safety net, manually analyzing and enriching each record. That safety net broke in February 2024, when the surge in reports pushed NIST to pause deep analysis. CISA and other Authorized Data Publishers stepped in, but the pipeline is now fragmented and buried in backlog.

No step in today's system requires a proof of concept or a working reproduction. A plausible-sounding fake advisory can slide through into GHSA, downstream databases, and enterprise scanners.

Red Flags for Spotting Slop CVEs

• Missing vendor corroboration. Nothing on the maintainer's official security page (for SQLite, check sqlite.org/cves.html).
• Absent commit history. No commit hash or pull request linked in the reference fields.
• Metadata contradictions. Empty CPE product definitions, or version ranges that contradict the advisory's own narrative.
• Non-existent code references. Functions that do not exist in the claimed version, or line numbers past the end of the file.

The Cost for Security Teams

Organizations with vulnerability management policies that mandate patching critical CVEs within a short window (ISO 27001-style programs, ITAR-driven requirements) will open tickets and burn hours on bugs that never existed. Scanners that auto-prioritize by CVSS will surface these records at the top of the list. The HN thread on JFrog's post, which drew 726 points and hundreds of comments, went straight to this: one commenter called it "fun for organizations that are mandated to patch all CVEs."

The worst case is an AI agent doing automated triage. It may try to locate the vulnerable function, generate a patch, or recommend changes against code that does not exist, leading a team down a wrong path instead of fixing anything real. A practical defense raised in the discussion: have an agent reproduce the issue in a sandbox before a human ever sees the ticket.

Frequently Asked Questions

Are these SQLite CVEs real? JFrog found that 54 of the 55 advisories from the account were fabricated. The six SQLite CVEs it audited in detail all fail verification.

Which CVEs are involved? CVE-2026-51302, CVE-2026-51303, CVE-2026-51300, CVE-2026-51297, CVE-2026-51296, and CVE-2026-51304, all filed against SQLite.

Did NVD get it wrong? NVD and CISA initially enriched these records as critical. After JFrog's report, at least one score (CVE-2026-51302) was downgraded from 10.0 to 7.6.

Is my SQLite installation vulnerable? As far as the research shows, no. None of the audited CVEs are real, and none are listed on SQLite's official advisory page.

How do I protect my pipeline from fake CVEs? Verify against the vendor's official advisory page, demand a commit hash or reproducing PoC, and reproduce the issue in a sandbox before acting.

Key Takeaways

• A single GitHub account pushed 55 advisories; 54 were fabricated, including six "critical" SQLite CVEs.
• NVD and CISA initially enriched the fake records as critical; scores were later downgraded.
• The verification method is reproducible: check vendor pages, diff the cited commits, run the PoC under ASan.
• Compliance-driven patching and AI triage tools are the most exposed to slop CVEs.

Sources

• JFrog: SQLite Critical CVEs or LLM Slop?
• The Register: AI slop pollutes the CVE pipeline with fake vulns
• Hacker News discussion
• SQLite official vulnerability page