Fake SQLite CVEs Rated 9.8 Critical Made It Into NVD

A GitHub account named programmervuln/cveadvisory- published more than 50 vulnerability advisories in late July 2026. NVD flagged several as Critical. CISA's Authorized Data Publisher program agreed. JFrog Security Research then tested six of the SQLite entries and found every single one described a vulnerability that does not exist. The broader audit result: 54 of 55 advisories were completely fabricated.

What the fabrications actually looked like#

CVE-2026-51302 claimed a heap use-after-free in exprComputeOperands(), triggered when sqlite3ReleaseTempReg() left a dangling pointer. NVD rated it 9.8 Critical. Red Hat initially assigned it 10.0 before lowering the score. The problem: exprComputeOperands() did not exist in SQLite 3.41.0. It was added in mid-2025. The function sqlite3ReleaseTempReg() recycles register indices into an array; it performs no heap deallocation, making a use-after-free structurally impossible. JFrog ran the PoC under AddressSanitizer. Normal query execution. No crash.

CVE-2026-51296, rated 7.5 High, cited a UAF in jsonRemoveFunc at lines 3555 and 3575 of json.c. Version 3.41.0's src/json.c is 2,706 lines long. The cited lines do not exist. CVE-2026-51303, rated 9.8 Critical, claimed a patch in SQLite 3.51.3. A diff between 3.51.2 and 3.51.3 shows zero changes to src/expr.c. The patch was fabricated wholesale.

GPTZero flagged the advisory text as AI-generated. That asymmetry, noted JFrog researcher Afek Berger, is the core problem: "Generative AI has lowered the effort required to produce a plausible-looking advisory to close to zero, while the effort required to verify one , review the source code, build the affected version, reproduce the PoC , is unchanged."

How the pipeline failed#

The CVE submission process via MITRE's public form requires no identity verification. Anyone can submit a vulnerability description and propose a CVSS score. Until 2024, NIST manually reviewed incoming records before NVD publication, acting as a practical filter. That stopped in February 2024 after a surge in submissions overwhelmed the agency.

The backlog grew to more than 17,000 unprocessed CVEs by late 2024. By end of 2025, a Department of Commerce Inspector General report put the number above 27,000. The DoC IG also concluded that NIST wasted money allocated to clearing the backlog due to "lack of strategic planning and decisive action." No step in the current system requires a reproducible proof-of-concept before a record publishes.

MITRE rejected the full batch after JFrog's disclosure. Alan Coopersmith of Oracle Solaris Engineering summarized the structural issue on the OSS-Security mailing list on July 31: "MITRE and most other CNAs operate on the honor system, and trust CVE requesters to have verified the information they provide."

Why this matters specifically for code review#

Every dependency scanner that ingests NVD feeds, which is most of them, is now carrying phantom CVEs in its output. Security teams in environments where Critical-rated findings automatically generate tickets or trigger CI failures will spend engineering hours investigating vulnerabilities that cannot be reproduced because the vulnerable code does not exist.

The problem compounds when automated triage is involved. JFrog noted that an agent encountering a fabricated CVE may attempt to locate the vulnerable function, generate a patch, or recommend changes based on code that was never there. The agent acts on advisory text rather than the actual repository. That is a first-order failure of any system that trusts the advisory feed without grounding the finding in the codebase itself.

Hyrax's security domain works differently. When Hyrax evaluates a vulnerability finding, it traces the claim against actual code paths in the repository under review. A CVE citing a function that does not exist in the target version produces no match. There is no ticket, no patch attempt, no wasted cycle. The advisory text is not sufficient; the code must confirm the exposure. That approach would have filtered every one of these 54 fabrications at the point of triage.

What signals to check before acting on a new CVE#

JFrog identified four indicators that a recently published advisory is likely fabricated:

• No mention of the issue on the official maintainer's security page (SQLite's advisory list at sqlite.org/cves.html contains none of these)
• No commit hash or pull request in the reference fields
• Missing or contradictory CPE metadata
• Code references pointing to functions absent from the claimed version, or line numbers past end-of-file

None of these checks require reproducing the exploit. They require five minutes of source inspection. The fabrications in this batch would have failed all four.

The noise floor just moved#

This incident is not isolated. The same structural gap that let 54 fake advisories reach NVD and CISA feeds will admit more. NIST's backlog is still growing. The submission process still has no reproduction requirement. Generative tools make plausible advisory prose cheap to produce at scale.

The practical consequence: teams whose security posture depends on advisory-text CVSS scores without code-level validation are carrying an increasing share of phantom risk in their backlogs. Real vulnerabilities sit in the same queue. The ratio is deteriorating, and there is no clear mechanism in the current pipeline to reverse it.

Hyrax is live at hyrax.dev.