CVE Requests Rose 10X as Verification Became the Bottleneck

By Grace Kim

GitHub’s CVE Numbering Authority received almost 4,000 CVE requests in May 2026, about 10 times the volume a year earlier. GitHub did not attribute that jump to AI or report a decline in submission quality. The Unite.AI analysis nevertheless argues that rising submission volume increases investigative work for maintainers and security teams regardless of whether reports are genuine.

What happened at SQLite?

Six CVEs were published against SQLite in July 2026. Two carried severity scores of 9.8. The reports appeared credible: they described memory-safety bugs and included technical explanations and proof-of-concept code. JFrog researchers found that some functions cited in those reports did not exist in the affected versions, and none of the proofs of concept reproduced the claimed vulnerabilities.

SQLite’s own CVE page now says the six reports are “not bugs”; the CVE records were subsequently rejected. The outcome did not establish deliberate fabrication.

A 9.8 severity label can reach public databases before reproduction confirms the underlying claim.

What makes a CVE “fake”?

The term “fake CVE” usually means a report was likely filed incorrectly, not that someone set out to mislead. The Unite.AI analysis says static analysis can miss a validation check or misread input as attacker-controlled.

A report can cite a real function yet describe an invalid attack path. An assigned CVE ID can later be discarded when the reported condition proves not to be a vulnerability.

The Unite.AI analysis also says vendors may dispute a researcher’s findings over exploitability, threat boundaries or whether a function was designed to handle untrusted input. Such a dispute is not proof of researcher error. Rejection does not necessarily mean fabrication; it can reflect duplicate or administrative reasons. A CVE identifier is not independent technical verification, and real reports still deserve serious treatment.

A rejected CVE signals failed review, not necessarily an attempt to deceive.

Why does verification cost so much?

The Unite.AI analysis says AI is lowering the cost of polished vulnerability claims. An AI model can flag a suspicious API call, sketch an exploit scenario and generate a professional-looking write-up with technical explanations and code references. A proof of concept can make an invalid claim look legitimate.

Verification can require checking the exact release, tracing control flow, following data into the function, building a test environment and running the alleged exploit. The Unite.AI analysis says the same process applies to accurate and inaccurate reports, which makes triage expensive.

Detailed claims are quick to produce; determining whether they describe real vulnerabilities remains time-consuming. The core operational need, according to the analysis, is to distinguish a reported vulnerability from a technically verified one.

Daniel Stenberg, who maintains curl, estimated last year that roughly 20% of incoming security reports were the product of “AI slop.”

The Unite.AI analysis says a false report can move through scanner feeds, security databases and search results faster than a correction reaches every downstream copy. The spread can cause reputational damage and leave vendors defending themselves with customers who saw the original announcement.

With limited resources, investigators can spend hours disproving false positives while genuine vulnerabilities wait, the analysis says. Every hour spent on an incorrect report reduces time available for an actual security issue.

False reports consume the same scarce engineering time as credible ones.

What should investigators verify first?

The Unite.AI analysis says many investigators still rely on manual triage, a load it calls unsustainable. It recommends automation that checks each claim against the actual affected release and configuration. Five questions set the minimum test:

• 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?

The Unite.AI analysis says agentic tools can create test environments, analyze code paths, generate proofs of concept and record execution evidence for human review. They cannot automatically resolve every claim. Even an authentic report may have a proof of concept that fails because its environment is incomplete or its trigger is wrong.

The analysis says a reproduced crash does not prove claimed exploitability, so human judgment remains crucial. These tools can still move teams toward a reproducible answer before a report consumes more time across engineering, vulnerability management and customer support.

Automation can shorten triage, but humans must still judge whether the evidence proves exploitability.

What would make intake more credible?

The Unite.AI analysis says no single concise policy can fix fake CVEs. It calls for stronger submission evidence, clearer reproduction status, clearer treatment of disputed records and faster correction of downstream data. It also encourages researchers to validate AI-assisted findings before submission.

Vendors and security teams still need to examine the evidence. A critical CVE score does not show whether a vulnerable path is reachable in their environment, and a failed proof of concept does not prove that all is well. Receiving a CVE ID does not excuse the technical work needed to understand an issue.

The Unite.AI analysis presents AI as a two-sided force: it can discover vulnerabilities and generate solid-looking but incorrect claims. It calls for investment in verification through tests, reproduction, assumption checks and easier-to-assess evidence, and sees agentic security testing as an important part of that response.

The Unite.AI analysis frames the next test clearly: if GitHub’s May volume persists, reproducible evidence and human judgment will decide whether AI-assisted discovery yields usable signal or a heavier reporting burden.