AI made vulnerability reports cheap. Verification isn't.
False positives, questionable CVEs, and the growing cost of checking vulnerability claims
AI can help uncover real vulnerabilities, but it can also produce convincing reports that don’t hold up under investigation.
As vulnerability reporting accelerates, the challenge isn’t just finding potential flaws, it’s establishing which claims are supported by evidence.
In this research, Edgescan examines the growing pressure on vulnerability disclosure processes. What happens when questionable CVEs enter public databases, and why technical verification matters more than ever.
What happens when a vulnerability report can't be trusted?
A CVE identifier gives a vulnerability claim a name. It doesn’t necessarily mean the underlying issue has been independently reproduced.
From rejected SQLite CVEs to the growing volume of vulnerability submissions, this research looks at the challenges facing maintainers: security researchers and organizations trying to separate credible findings from questionable claims.
What the research explores.
When vulnerability reports don’t hold up: the SQLite CVEs that were ultimately rejected and what their investigation tells us about the importance of evidence.
The growing cost of verification: why generating a convincing report can take minutes, while investigating its claims can take hours
When CVE records tell different stories: rejected, disputed, and withdrawn vulnerability records can leave conflicting information across security databases.
Why verification matters in the age of AI: explore the findings, real-world examples, and Edgescan’s perspective on the future of vulnerability verification.
Producing a polished vulnerability report has become easier. Verifying it can still mean tracing a function through multiple releases, checking third-party library documentation, reviewing a proposed proof of concept and establishing the attacker’s actual capabilities.
The curl project provides a documented example of the pressure this can create. Its maintainer, Daniel Stenberg, reported a substantial increase in low-quality vulnerability submissions and announced the end of curl’s bug bounty programme, effective 31 January 2026. curl continued to accept private security reports, but withdrew the financial incentive for submissions.
This is a cost borne by the people who maintain the software. Time spent ruling out an unsupported report is time that cannot be spent investigating a credible issue or fixing an existing defect.
These terms describe different states of evidence.
A rejected CVE record may represent an unused reservation, a duplicate, an incorrect assignment or a withdrawn security claim. A disputed record records disagreement about a claim; it does not, on its own, settle the technical question. And an AI-assisted report can be either correct or incorrect.
Treating all three categories as evidence of fabricated vulnerabilities would distort the picture. It would also overlook the genuine vulnerabilities being found with AI assistance.
These terms describe different states of evidence.
A rejected CVE record may represent an unused reservation, a duplicate, an incorrect assignment or a withdrawn security claim. A disputed record records disagreement about a claim; it does not, on its own, settle the technical question. And an AI-assisted report can be either correct or incorrect.
Treating all three categories as evidence of fabricated vulnerabilities would distort the picture. It would also overlook the genuine vulnerabilities being found with AI assistance.
The accompanying paper examines CVE rejection and dispute records from January 2024 through 29 October 2026, together with a set of publicly documented reports and technical case studies.
Its most important finding is a limitation in the available evidence. CVE status information does not reliably capture whether a report was AI-generated, and rejection records often retain little of the original technical claim. That makes it difficult to measure how much AI contributes to invalid vulnerability reporting, even when individual examples can be investigated.
The paper also identifies recurring weaknesses in questionable reports: references to functions or files that do not exist in the claimed version, incorrect readings of code or documentation, unsupported attack assumptions and defects that do not cross a security boundary. These are useful checks for any vulnerability report, regardless of how it was produced.
The paper’s full population-level figures are described in its methodology. Their independent reproduction requires the underlying dataset and analysis scripts.
A strong vulnerability report should give a reviewer a clear route from the claim to the evidence. At a minimum, that means identifying the affected product and version, locating the relevant code, explaining the attacker’s starting position and providing a reproducible demonstration or a technically sound explanation of impact.
AI can accelerate discovery and help researchers investigate unfamiliar code. It cannot remove the need for these checks. The goal is not to reject AI-assisted research, but to make sure that a claim earns trust before security teams act on it.
Read the research: *When Vulnerabilities Aren’t Real: An Empirical Investigation into False, Rejected, and AI-Generated CVE Reports During the Generative AI Era (2024–2026)*.
James Mullen
Head of Research at Edgescan
James Mullen is Head of Research at Edgescan, where he explores how AI is changing offensive security and vulnerability research. With a background in hands-on penetration testing, consultancy and R&D, James focuses on autonomous security testing, intelligent attack-surface discovery and AI-assisted vulnerability research. His work is grounded in a simple principle: AI can dramatically increase the speed and scale of security research, but findings still need to be proven, understood and validated.
Read more from Edgescan's Research team
I was looking back at CVEs that had already been …
AI developed for autonomous penetration testing is now surfacing potential …