AIが「捏造」した脆弱性情報が重大CVEとして公式登録される異常事態#
2026年7月、GitHubに新規作成されたリポジトリ「programmervuln/cveadvisory-」がSQLiteを含む50件以上の脆弱性アドバイザリを公開した。NVDはこれらを迅速に「重大（Critical）」として登録し、CISAのADPも同様に認定。ところが、JFrogのセキュリティ研究者がひとつひとつ検証したところ、これらはLLM（大規模言語モデル）が生成した「スロップ（質の低いAI生成コンテンツ）」である可能性が高いことが判明した。
検証で明らかになった6つの偽CVEの実態#
JFrogの研究者・Afek Berger氏は、公式SQLiteリポジトリのクローン、Dockerコンテナ内でのクリーンビルド、AddressSanitizer（ASan）を使ったPoC実行、そしてNVDメタデータの精査という体系的な手順で各CVEを検証した。その結果は以下の通りだ。
CVE-2026-51302（CVSS 9.8 Critical）#
アドバイザリはexprComputeOperands()という関数でのヒープ解放後使用（UAF）を主張していたが、この関数はSQLite 3.41には存在しない。2025年中頃のコミットで追加されたものだ。また、問題の関数sqlite3ReleaseTempReg()はヒープメモリの解放を行わず、レジスタのインデックスを再利用するだけの処理であり、設計上UAFは起こり得ない。PoC実行でもクラッシュは発生しなかった。
CVE-2026-51303（CVSS 9.8 Critical）#
ExprListDelete()での不具合がバージョン3.51.3でパッチされたと主張していたが、3.51.2と3.51.3の差分を確認するとsrc/expr.cにはまったく変更が加えられていない。「パッチ」自体が完全な捏造だった。PoCのSQLは構文エラーでパーサー段階で失敗し、実行ロジックに到達すらしなかった。
CVE-2026-51300（CVSS 9.1 Critical）#
アドバイザリが引用したexpr.cの具体的な行番号（1012行目と1026行目）は、それぞれコメントとメモリ確保の呼び出しであり、指摘された削除ロジックとは無関係だった。PoCは正常なSQLクエリとして実行され、メモリリークもエラーもゼロだった。
CVE-2026-51297（CVSS 8.8 High）#
jsonBlobEdit()という関数を問題の起点として挙げていたが、この関数もバージョン3.41.0には存在しない。JSONBの実装時に後から追加されたものだ。PoCはJSON形式エラーで即座に失敗した。
CVE-2026-51296（CVSS 7.5 High）#
json.cの3555行目と3575行目を問題箇所として引用していたが、SQLite 3.41.0におけるsrc/json.cの総行数はわずか2706行であり、引用された行番号は物理的に存在しない。
CVE-2026-51304（CVSS 7.5 High）#
関数のシグネチャ（引数の数）が実際のコードと異なっており、実際にはデータベースコンテキストへのポインタが必要な引数が省略されていた。さらにSQLiteは削除直後にポインタをNULLクリアするコードが明示的に書かれており、UAFは構造的に不可能だった。
なぜ偽CVEが「重大」として通ってしまったのか#
ソース記事によると、MITREの公開フォームを通じたCVE申請には実質的な本人確認が存在しない。歴史的にはNISTのNVDがCVEを手動で検証・精査する「安全網」として機能していたが、2024年2月以降、膨大な脆弱性報告の増加によりNISTはこの深い分析を事実上停止した状態にある。CISAなど他の認定データパブリッシャー（ADP）が補完しようとしているものの、現在のパイプラインは断片化し、大量の未処理案件を抱えている。PoC（概念実証コード）や再現性の確認を必須とするステップが存在しないため、もっともらしく聞こえる偽のアドバイザリがそのまま通過し、GHSA等の下流データベースに流れ込む状況となっている。
なお、今回問題となったリポジトリの全アドバイザリをAI検出ツール「GPTZero」でテストしたところ、AI生成コンテンツの警告が表示されたとJFrogは報告している。また、最初はRed HatがCVE-2026-51302にCVSSスコア10.0（Critical最高値）を付与していたが、JFrogの調査が進む中でスコアは7.6（High）に引き下げられた。
まとめ#
JFrogの今回の調査は、存在しない関数名・不正確な行番号・架空のパッチという3種類の「ハルシネーション（AIの幻覚）」パターンが、CVEの審査プロセスをすり抜けて重大脆弱性として登録されうることを実証した。SQLiteの公式アドバイザリページには該当CVEが一切掲載されていないことも、信頼性の欠如を裏付けている。
筆者の見解: AIによるコンテンツ生成が低コスト化した現在、このような「LLMスロップ」CVEは今後も増加すると考えられる。セキュリティ担当者はNVDのスコアだけを鵜呑みにせず、公式ベンダーのアドバイザリや独立した検証結果を併せて確認する習慣がこれまで以上に重要になるだろう。
出典: SQLite Critical CVEs or LLM Slop? - JFrog Security Research
