Article URL: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ Comments URL: https://news.ycombinator.com/item?id=49154332 Points: 156 # Comments: 41

Over the past few days, a newly created GitHub repo (programmervuln/cveadvisory-) published a batch of SQLite vulnerability advisories (as part of other 50+ CVEs which we believe are also LLM slop except from one). NVD quickly flagged these as critical, and CISA's ADP agreed. But when JFrog security researchers dug in to verify, the claims fell apart: This made us question the reliability of these CVEs as well as understanding that these CVEs may be LLM slop. While investigating one of the CVEs yesterday, CVE-2026-51302, we saw that Red Hat initially assigned it a 10.0 Critical severity score: Looking at the CVE again today, we noticed that the score has since been downgraded to 7.6 High. To verify these reports thoroughly, we established an isolated testing workflow: Reported Vulnerability: The advisory claims a heap use-after-free occurs when sqlite3ReleaseTempReg() leaves a dangling pointer in regFree1, which is later dereferenced by exprComputeOperands(). Finding: The primary issue here is that exprComputeOperands() didn't exist in SQLite 3.41. It was added in the middle of 2025 (commits e24f20a, 280559b). Furthermore, the mechanics of sqlite3ReleaseTempReg() do not involve heap deallocation. The function simply recycles register indices into an array for reuse, making a UAF impossible by design. PoC Testing: The query ran successfully without triggering a crash because the bug does not exist.