Six vulnerabilities alleged to exist in SQLite were all retracted just four days after the CVE records were published. During that window, CISA's supplementary layer had already added CVSS scores ranging from 7.5 to 9.8 and classifications indicating "use-after-free" to each record. But when JFrog built the affected versions and checked them against the actual code and proof-of-concept exploits, they found, one after another, functions and line numbers that didn't exist, and fixes that were entirely fictional. Both JFrog and the SQLite developers have raised suspicions of AI generation. What this incident has exposed is the gap between the cost of submitting a plausible-looking report and the cost a human must bear to prove it wrong.
Six CVEs, Including One Scored 9.8, Collapse Under Code Verification
On July 27, 2026, MITRE published six CVEs alleged to be vulnerabilities in SQLite. All six claimed use-after-free conditions, said to lead to denial of service, information disclosure, or arbitrary code execution. CISA's Authorized Data Publisher (ADP) added CVSS v3.1 scores to all six, rating CVE-2026-51303 at 9.8 and CVE-2026-51300 at 9.1. Several records were also tagged with "Exploitation: poc," indicating that exploit code existed.
Rather than judging the plausibility of the write-ups, JFrog built SQLite versions 3.41.0, 3.51.2, and 3.51.3 in an isolated Docker environment, enabled AddressSanitizer, and ran the PoCs. The result: none of the six reproduced any crash or memory error.
| CVE | Where the claim falls apart | CISA ADP CVSS before rejection |
|---|---|---|
| CVE-2026-51302 | exprComputeOperands() does not exist in the affected version |
7.5 |
| CVE-2026-51303 | No change was made to expr.c in 3.51.3, the version claimed to contain the fix; the PoC fails during parsing |
9.8 |
| CVE-2026-51300 | The referenced line is a comment/memory allocation; the PoC exits normally | 9.1 |
| CVE-2026-51297 | jsonBlobEdit() does not exist in the affected version |
8.8 |
| CVE-2026-51296 | References lines 3555 and 3575 in a file that only has 2706 lines | 7.5 |
| CVE-2026-51304 | Cites the wrong function arguments; the actual implementation zeroes the pointer after freeing it | 7.5 |
Whether the text "sounds" AI-generated is only a secondary clue. What actually brought down these six CVEs was the source code of the affected versions and the execution results. The SQLite developers now list all six as "unreproducible" and "apparently AI hallucinations," explicitly stating they are not SQLite bugs.
JFrog examined 55 CVEs associated with the same GitHub account and reported that 54 were pure fabrications, while the remaining one attached unverified CVE details to a bug that actually existed. That said, JFrog did not reproduce and verify those 55 with the same rigor as the six SQLite cases. The one fact that can be traced with certainty is that MITRE changed the status of all six to REJECTED on July 31, with the reason field noting that "further investigation determined that this was not a security issue."
CVE, CISA, and NVD Are Separate Processes
To understand where the misinformation slipped through, it helps to separate three distinct roles. A CVE Numbering Authority (CNA) determines whether a vulnerability exists and publishes an identifier and record. CISA's ADP adds CVSS, CWE, SSVC, and other data to a separate container attached to the already-published record. NIST's National Vulnerability Database (NVD) automatically ingests the CVE List roughly an hour after publication and independently adds items such as CPEs to represent affected products.
CVE operating rules require a CNA to have "reasonable evidence" that a vulnerability exists before assignment. At the same time, the rules state that when a determination cannot be made clearly even after a good-faith check, the benefit of the doubt should go to the assigning side, so that identification and discussion can proceed. There is no uniform requirement that the CNA itself must reproduce a PoC for every case. For already-published cases, if the most appropriate CNA declines or fails to respond to an assignment within 72 hours, the relevant Root determines whether the vulnerability exists.
This design exists to quickly assign a common name to vulnerabilities worldwide. The CVE Program itself states that a CVE ID is a common identifier, not an instruction that by itself determines whether remediation is needed or how much risk is involved. The problem exposed here is that even when the premise of a base record is false, the later supplementary steps flesh out the CVSS and CWE fields, making the record look more informative to anyone downstream. Because the ADP cannot modify the area written by the CNA, the supplementary process is no substitute for re-verifying the original claim.
Indeed, CVE-2026-51300 had a 9.1 score and an "Exploitation: poc" tag added by CISA's ADP, but when JFrog ran the attached query, it returned a normal result with no memory error at all. The richness of structured data and the actual likelihood that a vulnerability exists need to be treated as separate matters.
The Processing Pressure of 15,176 Records in a Single Quarter
In Q1 2026, the CVE Program published 15,176 records, up 19% from 12,796 in the previous quarter. Reserved IDs reached 21,530, up 39% from 15,479. The Program has attributed part of the increase in reservations to a rise in AI-driven vulnerability discovery and submissions. This figure doesn't tell us how many of those reports were fake, but it clearly shows a shift in the volume that verifiers must handle.
Processing pressure also weighs on post-publication supplementation. According to the U.S. Department of Commerce's Office of Inspector General, NVD's backlog of unprocessed records swelled from roughly 13,000 in early June 2024 to over 27,000 by the end of 2025. Annual submission counts for 2026 are projected to exceed 60,000. For NVD analysts, assigning severity scores and CPE-based applicability is estimated to consume about 80% of their working time.
That said, there's no evidence that NVD's backlog directly caused this particular misassignment. Assignment happens on the CVE side; supplementation happens on the CISA and NVD side. Since neither stage is structured to build and reproduce PoCs for every single submission, as the volume of submissions grows, the cost of verification gets pushed back onto vendors and outside researchers.
That burden is already straining development work. Curl suspended acceptance of vulnerability reports for the entire month of July 2026. Maintainer Daniel Stenberg reflected on August 3 that stepping away from report handling allowed him to redirect time back toward reviewing backlogged features and changes. He also noted that, outside of curl, other security teams had not seen any letup in the flood of reports. Even as the cost of sending a single fake report drops, the party proving it's false still has to read, build, and run the affected code.
Five Things to Check Before Trusting a CVE Number
When a new CVE surfaces, it's fast to auto-file a ticket based on the number and CVSS score alone. But rushing straight to an emergency patch based on that lets records like these consume investigation time—or even trigger unnecessary code changes. At minimum, an operational workflow needs to surface the following five checks on the same screen:
- Has the product's vendor or developer acknowledged the issue?
- Is there a fix commit or pull request that actually corresponds to the claimed code?
- Do the function, line number, and execution path actually exist in the affected version?
- Does the PoC reproduce in a safe, isolated environment, with observed results matching the description?
- Where did the CVSS, CWE, and CPE values come from—the CNA, CISA's ADP, or NVD?
This checklist isn't about abandoning CVEs or automation. It's about a division of labor: using the CVE ID as a correlation key while deciding remediation priority based on vendor information and reproducible evidence. These six cases are already REJECTED and must not be used as grounds for an emergency SQLite update. Whether the same mistake can be stopped next time depends on whether scanners promptly reflect rejected status, and whether organizations can build vendor confirmation and evidence checks into automated processes that currently move on scores alone.