SQLiteのcritical CVE騒動、未検証LLM advisoryが増やす負担

JFrog Security Researchは、最近公開されたSQLite関連のCVE advisory群を検証し、複数のcritical claimが実際のソースコードと合わないと報告した。新しく作られたGitHubリポジトリがSQLiteの脆弱性advisoryを大量に公開し、NVDやCISA ADPのmetadataにも高いseverityが反映された。JFrogは公式SQLiteリポジトリの該当タグを取得し、隔離されたDocker環境でbuildし、PoC SQLをAddressSanitizer付きで実行した。その結果、多くの主張は再現できなかった。

例はかなり具体的だ。CVE-2026-51302では、SQLite 3.41.0のexprComputeOperands()にuse-after-freeがあるとされたが、JFrogによればその関数は当該versionに存在しない。CVE-2026-51303はSQLite 3.51.3でsrc/expr.cが修正されたかのように説明していたが、3.51.2との差分に該当変更はなかった。CVE-2026-51296は、対象versionのjson.cには存在しないline numberを指していた。

ここで重要なのは、LLMがsecurity researchに使えないという話ではない。fuzzing、triage、code navigation、exploitability reviewでは役に立つ場面がある。問題は、生成されたadvisoryが、関数名、line number、version、実行経路の基本確認を通る前に「critical CVE」として流通することだ。脆弱性対応チームはすでにfalse positiveとalert fatigueに悩まされている。存在しないコードに基づくcritical alertは、本物の脆弱性を見る時間を削る。

HNの議論もそこに集中した。コメントでは、advisory systemが偽報告で埋まる攻撃面、NVD metadataに依存するdownstream scannerの負担、そしてsignal-to-noise ratioの低下が話題になった。元記事はJFrog Security Researchの分析で、議論はHacker Newsにある。