SQLite and Chromium Security have warned that inaccurate and AI-generated vulnerability reports can consume substantial review time, as technically detailed claims may cite nonexistent code, files, or security flaws.
SQLite and Chromium Security have separately warned that vulnerability reports cannot be treated as reliable simply because they look detailed or carry a CVE identifier. Their guidance highlights a growing challenge for software maintainers: technically plausible reports may still describe nonexistent flaws, forcing security teams to spend time validating claims before they can be dismissed.
Chromium Security’s guidance, “Shepherding AI Reports”, says the project has seen an increase in vulnerability submissions that are partially or entirely generated by AI. The document says these reports may include hallucinated functions, source files, and stack traces.
Those fabricated details can make a submission appear precise, but they do not establish that a vulnerability exists. Chromium recommends grounding triage in evidence, including confirming that the relevant code exists, checking the claimed execution path, and seeking a reproducible demonstration of the reported behavior.
SQLite’s Vulnerabilities page similarly cautions that third-party CVE records concerning the project can contain inaccuracies. SQLite says its developers often learn of a reported issue after the underlying bug has already been fixed.
The project’s warning matters because a CVE identifier is often interpreted as confirmation of a present and actionable security vulnerability. SQLite argues that a third-party CVE entry alone should not be taken as proof that its description, affected versions, or security assessment is correct.
That can create a difficult situation for open-source projects. Public vulnerability records may be published without maintainers’ involvement, while users and downstream distributors may rely on descriptions that do not accurately reflect the code or the project’s own analysis.
The problem is especially acute when automated tools can quickly produce long reports using security terminology and references to software internals. A report that initially appears credible may require substantial engineering effort to inspect, reproduce, reject, or clarify.
TechCrunch reported in July 2025 that AI-generated and fabricated submissions were exhausting some bug-bounty and security programs. The report described claims that could appear plausible during an initial review but were ultimately hallucinated, placing added pressure on teams responsible for assessing security findings.
Neither SQLite nor Chromium suggests that AI assistance automatically makes a report invalid. The useful distinction is evidentiary: a strong report identifies an affected component, accurately describes the relevant code or behavior, includes a reproducible proof of concept where appropriate, and explains the security impact.
For maintainers, the concern is that generative AI lowers the cost of producing technical-sounding submissions without lowering the cost of verifying them. As a result, security programs may need to apply more rigorous initial checks to protect time for confirmed vulnerabilities and fixes.
Security teams face a new review burden SQLite and Chromium Security have separately warned that vulnerability reports cannot be treated as reliable simply because they look detailed or carry a CVE identifier.
Chromium Security’s guidance, “Shepherding AI Reports”, says the project has seen an increase in vulnerability submissions that are partially or entirely generated by AI.
The document says these reports may include hallucinated functions, source files, and stack traces.
Continue reading
