JFrog’s SQLite investigation is a useful warning because it shows the failure at the point where software security becomes operations. A newly created GitHub repository published SQLite vulnerability advisories that were picked up by official-looking downstream systems, including NVD severity metadata. Several were marked Critical before the claims survived basic validation.
JFrog checked the reported flaws against official SQLite source, built affected versions in isolated Docker containers, and ran the provided proof-of-concept payloads with AddressSanitizer. The reported code paths often did not exist in the referenced versions, the PoCs did not trigger crashes or memory errors, and none of the CVEs appeared on SQLite’s official advisory page. In a broader audit of 55 advisories from the same account, JFrog found 54 were completely fabricated and one mixed a real bug with unverified CVE metadata.
Grey Haven’s read: this is not just “LLM slop” as bad content. It is slop as workflow input. Security programs increasingly route advisories into ticket queues, patch prioritization, vendor risk reviews, and executive dashboards. Once fake advisories enter that machinery, the cost is paid by engineers, security analysts, and operations teams who must disprove nonsense under urgency.
The operator implication is straightforward. Any AI-assisted AppSec or dependency-risk workflow needs a provenance gate before severity scoring or remediation assignment. Required checks should include source reputation, affected-version source inspection, reproducible PoC behavior, vendor advisory alignment, and a quarantine state for unverified CVE metadata.
Watch whether vulnerability databases and scanners add confidence, provenance, and reproducibility signals rather than only CVSS labels. If they do not, automated security pipelines will become very efficient machines for turning synthetic claims into real work.
Source: JFrog Security Research, “SQLite Critical CVEs or LLM Slop?”
