Beckmann
Security

JFrog exposes 54 out of 55 SQLite reports as AI forgery

An IT security researcher uncovered through Docker tests: 54 out of 55 reported SQLite vulnerabilities existed only in AI-generated CVE reports.

By Published on

2 min read

TL;DR Too Long; Didn’t read

The IT security company JFrog has exposed 54 out of 55 alleged SQLite vulnerabilities from a GitHub account as AI inventions. Six reports initially received critical ratings of up to 9.8 out of 10 points, although the mentioned features were missing in the source code. Only one of the 55 reports contained a real error. JFrog informed GitHub, Red Hat, and the US database NVD.

A magnifying glass with a JFrog logo sticker examines several red, bursting warning-label bubbles rising from a cylindrical database container labeled SQLite. Image generated with GPT Image 2

Key takeaways

  • JFrog tested all six critical reports in isolated Docker containers – none could be reproduced.
  • An AI detection tool classified the advisory texts of the GitHub account as machine-generated.
  • Red Hat initially rated one of the forgeries with the maximum score of 10.0 out of 10 points.
  • According to JFrog, the forgeries were created within four days through the same GitHub account.
  • Since February 2024, the US vulnerability database NVD has hardly been manually reviewing submitted reports due to capacity reasons.

The IT security company JFrog has revealed that 54 out of 55 alleged security vulnerabilities in the SQLite database were completely fabricated – published through a single GitHub account within four days. Six of the reports initially reached critical values in official databases of up to 9.8 out of 10 points, even though the described functions did not exist in the actual SQLite source code.

Incorrect function names expose the AI origin

JFrog security researcher Afek Berger examined six advisories, all claiming use-after-free errors in SQLite – such as in the functions exprComputeOperands(), ExprListDelete(), and sqlite3ExprDelete(). The six reports carried the identifiers CVE-2026-51302, CVE-2026-51303, CVE-2026-51300, CVE-2026-51297, CVE-2026-51296, and CVE-2026-51304, with CVSS values between 7.5 and 9.8. To verify the claims, the team cloned the official SQLite source code, compiled the mentioned versions in isolated Docker containers with AddressSanitizer instrumentation, and executed the provided code examples verbatim. None of the six errors could be triggered. In several reports, the advisories referred to line numbers that extended far beyond the end of the respective source file – in one case to line 3575 in a file with 2,706 lines. Other reports mentioned functions that simply did not exist in the specified SQLite versions. A tool for detecting AI-generated texts additionally classified the wording of the advisories as machine-generated. JFrog then expanded the review to all 55 reports from the same GitHub account: 54 turned out to be completely fabricated, and only one finding contained a real, albeit poorly documented, error.

Evaluation bodies initially assign maximum values

The fakes passed through the official CVE process before they were noticed. Red Hat initially assigned the report CVE-2026-51302 the maximum value of 10.0 out of 10 points and lowered it to 7.6 after JFrog’s notification. On the platform X, JFrog Security stated that the submitted evidence did not match the assigned critical rating. JFrog informed not only Red Hat but also the GitHub Security Advisory Database and the US vulnerability database NVD about the finding. Who is behind the GitHub account and with what purpose the reports were published remains unverified independently. Similar patterns are not an isolated case: already in July, Apple restricted its bug bounty program after AI-generated reports had overwhelmed the review team, while independent data simultaneously showed a sudden increase in real, AI-discovered vulnerability reports at large technology companies. According to JFrog, the CVE submission does not require identity verification, and the NVD has significantly reduced its manual review capacity since February 2024.

It will be crucial whether NVD and GHSA introduce stricter submission rules, such as a requirement for verifiable code examples or commit references – so far, neither of the two bodies requires such proof. Until such a reform occurs, security teams have no choice but to check each new critical report against the actual source code before patching.

Frequently asked questions

Are SQLite applications at risk from the false reports?

No, the six reviewed critical reports could not be reproduced in any test, and the SQLite maintainers have not confirmed the CVEs. Real risks arise at most indirectly when scanners mistakenly classify systems as vulnerable.

Who is behind the GitHub account with the forgeries?

The account appeared under the name 'programmervuln'; the actual identity and motive of the operators are independently unverified.

How do professionals recognize AI-generated CVE reports?

Typical warning signs are a lack of confirmation from the software manufacturers, references to non-existent lines of code or functions, as well as programming examples that cannot be reproduced.

Have there been such cases before the SQLite affair?

Yes, among other things, Apple had to limit its bug bounty program in June 2026 due to a flood of AI-generated error reports.

What can NVD and GitHub change specifically now?

JFrog suggests that submissions should in the future require identity verification as well as traceable commit references or programming examples to automatically filter out generated forgeries early.

#Security
Sources (2)
  1. SQLite Critical CVEs or LLM Slop? – JFrog Security Research
  2. JFrog Security on X

Your AI update for the work week

Once a week, the most important AI news – plus one practical tip to try right away. No spam, unsubscribe anytime.

Related articles

← Back to the blog