Fake CVEs, AI-Generated Reports and the Need for Verification

It’s becoming cheaper to create convincing vulnerability reports, and that’s increasing the consequences for software maintainers and security teams. Six Common Vulnerabilities and Exposures (CVEs) were published against SQLite in July 2026, and two of them received a severity score of 9.8. The reports seemed legitimate, describing memory-safety bugs and including technical explanations and proof-of-concept code.

But JFrog’s researchers discovered that some of the functions these reports referred to were not in the affected versions. What’s more, none of the proofs of concept (PoCs) reproduced the claimed vulnerabilities. SQLite’s own CVE page currently says these six reports are not bugs; the CVE records were subsequently rejected.

The problem goes beyond SQLite. The man who maintains curl, Daniel Stenberg, estimated last year that roughly 20% of incoming security reports were the product of AI slop. GitHub’s CVE Numbering Authority (CNA) received almost 4,000 CVE requests in May 2026; that’s about a 10X increase in volume year-over-year. GitHub didn’t blame this increase on AI or note a decrease in submission quality, but the massive volume growth underscores the overwhelm in the vulnerability disclosure process.

AI is making it easier to create detailed vulnerability claims, it’s time-consuming to determine whether these claims are legitimate. And once a CVE enters security feeds and public databases, correcting the original record doesn’t automatically mean every copy gets corrected. This creates a growing need to distinguish a reported vulnerability from a technically verified one.

What Is a “Fake” CVE?

People routinely use the term “fake CVE” to highlight a CVE that was likely reported incorrectly. But fake doesn’t mean intentionally misleading. It could come from static analysis that overlooks a validation check or misinterprets input as being controlled by an attacker. A report may detail a real function but claim an invalid attack path. An identifier (CVE ID) can be assigned and later thrown out if the condition reported was not, in fact, a vulnerability. That’s different from a deliberately fictitious report.

A dispute is not a fake CVE, either. A vendor may dispute a researcher’s findings about exploitability, threat boundaries or whether a function was intended to process untrusted input. But a dispute isn’t proof that the researcher erred. And rejecting a CVE doesn’t necessarily mean it was fabricated; it may get rejected as a duplicate or for administrative reasons. Though a CVE identifier is not independent technical verification, the industry needs to take real reports seriously.

Why Fake CVEs Are a Problem

One of the problems we’re seeing is people using AI to generate vulnerability reports without properly validating the findings. These reports can include detailed technical explanations, code references and even PoCs, which can make them look legitimate. But as we saw with the SQLite CVEs, some of the referenced functions didn’t even exist in the affected versions.

GitHub reported a significant increase in vulnerability submissions in 2026, although it didn’t attribute that increase to AI or report a decline in submission quality. The concern is that as the number of reports increases, so does the amount of work required to investigate them, regardless of whether the findings are genuine.

For those who have triaged vulnerability reports, it’s easy to recognize the practical difficulty. An AI model can identify a suspicious API call, rough out an exploit scenario and quickly generate a professional-looking write-up. Determining whether that scenario is viable may require checking the exact release, tracing control flow, learning how data reaches the function, building a test environment and running the alleged exploit. It’s the same process whether the report is accurate or not, and that can be expensive.

Fake CVEs can do reputational damage, as well. A vulnerability announcement can quickly disseminate across scanner feeds, security databases and search results. However, a consequent correction may not extend as far. Even once a report has been disputed or rejected, vendors can find themselves on the defensive with customers who saw the original report.

There’s also the risk of genuine vulnerabilities being overlooked or delayed because teams are spending time investigating incorrect reports. When maintainers and security teams have limited resources, every hour spent disproving a false positive is time that could have been spent investigating an actual security issue.

Fighting Back with Automation

Many investigators are still using manual triage to address the new deluge of reports, but this is not sustainable. Automation proves a great aid in helping to verify a vulnerability claim against the actual affected release and configuration. These are the five questions to ask:

• Are the attack prerequisites credible, including configuration and permissions?
• Does the purported function exist in the affected version?
• Can an attacker reach the vulnerable code? Determine whether the relevant code can execute under the affected conditions and whether an attacker can supply input that reaches it.
• Can testers reproduce the behavior in a controlled test or with a PoC?
• Does the observed behavior exhibit the security impact described in the advisory?

Agentic tools can create test environments, analyze code paths, generate PoCs and record execution evidence for review. They can’t automatically resolve every claim. Even when a vulnerability is authentic, a PoC can fail if the environment is incomplete or the trigger is wrong. Testers can reproduce a crash without proving the claimed exploitability. These caveats are why human judgment remains crucial. But these tools can get teams closer to a reproducible answer before a report swallows more time across engineering, vulnerability management and customer support.

Overcoming Overwhelm in the CVE Ecosystem

No one concise policy will magically fix the issue of fake CVEs. But it would help to require stronger submission evidence and to have clearer reproduction status. It would also help to have clearer treatment of disputed records and faster correction of downstream data. Researchers should be encouraged to validate their AI-assisted findings before submission.

Security teams and vendors must focus on examining the evidence. A critical CVE score doesn’t disclose if a vulnerable path is reachable in their environment. Just because a PoC fails, that doesn’t mean all is well. And receiving a CVE ID doesn’t excuse teams from undertaking the technical work required to understand an issue.

AI is enhancing the ability to discover vulnerabilities, and it’s also enabling the creation of solid-looking but incorrect claims. In a world of proliferating reports, organizations need to invest in verification. It consists of building tests, reproducing results, checking assumptions and making evidence easier to assess. This is an area where agentic security testing could play an important role.