出来事の日付：2026年8月3日。 JFrog Security Researchは、SQLiteに関する複数の主張をテストし、データベースエンジンのソースコードと照合した結果、その大半が捏造されたものだとする一連の脆弱性勧告に異議を唱えた。研究者らによると、あるGitHubアカウントに関連する55件の勧告のうち54件は誤りで、残る1件は実在するバグを説明していたものの、未検証のCVE情報が付随していた。
それにもかかわらず、問題の報告は著名なセキュリティシステムに登録されていた。JFrogによると、National Vulnerability Database（NVD）は当初、SQLiteに関する項目を「緊急」と評価し、CISAのAuthorized Data Publisherもその評価に同意した。調査会社の報告では、Red Hatは当初、CVE-2026-51302に深刻度スコア10.0を付け、その後7.6に引き下げた。
JFrogは隔離されたテストプロセスを構築し、勧告の説明が該当するSQLiteのバージョンと一致するかどうかを調べた。その結果、いくつかの基本的な矛盾が明らかになった。ある主張はSQLite 3.41には存在せず、2025年になって初めて導入された関数に依存していた。別の主張では、不具合がバージョン3.51.3で修正されたとされていたが、JFrogは3.51.2と3.51.3の間で、引用されたソースファイルに対応する変更を確認できなかった。
ほかの報告には、無関係なコードを指す行番号、実在しないシグネチャで呼び出される関数、あるいは該当するソースファイルの総行数を超える行への言及があった。研究者らはまた、複数の概念実証用入力について、メモリエラーを起こさずに実行されたか、脆弱とされるロジックに到達する前の解析段階で失敗したことを確認した。ある事例では、主張された解放後使用（use-after-free）は、ヒープメモリを解放するのではなくレジスター番号を再利用するルーチンに依存しており、説明された仕組みは実装と両立しなかった。
この調査結果はSQLite以外にとっても重要だ。脆弱性フィードは自動的な作業を引き起こす可能性があるためだ。「緊急」というスコアによってチケットが作成されたり、修正計画の優先順位が変更されたり、自動化エージェントが関数を探して修正するよう促されたりすることがある。元の勧告が架空であれば、こうしたシステムはエンジニアリングの時間を消費し、不要なコード変更さえ助長しかねない。
JFrogは、この問題を、より広範なCVEエコシステムにおける人手による情報補完の縮小と関連付けた。同社によると、提出件数の急増を受け、NISTは2024年2月に詳細な分析を縮小し、ほかの発行機関は増大する未処理案件への対応を試みた。研究者らは、提出手続きではバグの再現が求められないため、もっともらしく見えても裏付けのない報告が、下流のデータベースやスキャナーに拡散し得ると論じた。
JFrogは、調査結果をGitHub Security Advisories、Red Hat、National Vulnerability Databaseに報告したとしている。同社の調査は、データベース上の深刻度ラベルを欠陥が存在する証拠として扱う前に、勧告をソースコード、バージョン履歴、再現可能なテストと照合して検証する必要性を裏付けている。
