ハルシネーションを起こしたSQLite CVE: 脆弱性報告におけるLLMスロップの台頭

LLMが生成した偽のCVEがSQLiteを標的に

最近のSQLiteに関するセキュリティアドバイザリが「LLMスロップ（LLM slop）」、つまり人工知能によって捏造された脆弱性であることが判明しました。これらは、National Vulnerability Database (NVD) や CISAのAuthorized Data Publishers (ADP) によって、重要（critical）としてフラグが立てられていました。JFrogのセキュリティ研究者は、GitHubリポジトリ (programmervuln/cveadvisory-) が50件以上のCVEを公開しており、その大部分が完全に偽物であり、SQLiteを標的とした複数の高深刻度（high-severity）の報告が含まれていることを発見しました。

捏造の証拠

JFrogは、公式のSQLiteタグのソース検査、Dockerでのクリーンな環境でのビルド、およびAddressSanitizer (ASan) 下でのPoC実行を含む、厳格なテストワークフローを通じて、これらのCVEの虚偽性を検証しました。調査の結果、ハルシネーション（幻覚）の4つの主要なパターンが明らかになりました。

1. 存在しないコード参照

いくつかのアドバイザリは、SQLiteの対象バージョンに存在しない関数や行番号を引用していました。例えば、CVE-2026-51302は、exprComputeOperands()という関数における脆弱性を主張していましたが、この関数は報告されたバージョン3.41.0よりもずっと後の、2025年中盤までSQLiteに追加されていませんでした。同様に、CVE-2026-51296は、src/json.c内の行番号が実際のファイルの長さを超えていました。

2. 捏造されたパッチ

CVE-2026-51303は、バージョン3.51.3で修正が実装されたと主張していました。しかし、バージョン3.51.2と3.51.3の間のdiffを確認したところ、関連するファイル (src/expr.c) に変更は全く見られず、「パッチ」が完全に捏造されたものであることが証明されました。

3. 無効なPoCペイロード

アドバイザリで提供されたProof-of-Concept (PoC) SQLステートメントは、クラッシュやメモリエラーを引き起こすことができませんでした。いくつかのケースでは、PoCは無効なSQLであり、パーサー段階で失敗しており、標的としていると主張する実行ロジックに到達していませんでした。

4. 論理的な不可能性

CVE-2026-51304では、アドバイザリはリストが解放された後にuse-after-free (UAF) が発生すると主張していました。ソースコード分析の結果、SQLiteは削除直後にポインタを明示的にnullにしている (pPrior->pOrderBy = 0) ため、その後のデリファレンスは設計上不可能です。

CVEパイプラインのシステム的な失敗

この事件は、世界的な脆弱性報告インフラストラクチャにおける重大な脆弱性を浮き彫りにしています。現在のシステムでは、主に以下の2つの要因により、もっともらしく聞こえる偽のアドバイザリが企業向けスキャナーに到達してしまいます。

  • 本人確認の欠如: MITREの公開提出フォームは本人確認を必要としないため、誰でもCVEとCVSSスコアを提案することができます。
  • 「NVDセーフティネット」の崩壊: 歴史的に、NISTの専門家がCVEを検証し、情報を拡充してきました。しかし、2024年2月以降、報告数が激増したため、NISTは詳細な分析を一時停止しており、パイプラインが断片化し、強制的なPoCや再現手順の欠如を招いています。

セキュリティ運用への影響

捏造されたCVEは、セキュリティチームやメンテナーに対して、重大な運用上の負担を強いています。

  • リソースの浪費: 組織は、存在しないバグの調査やパッチ適用に時間を費やしてしまいます。特に、自動化されたシステムがCVSSスコアに基づいて高優先度のチケットを生成する場合、その影響は大きいです。

  • メンテナーの燃え尽き: プロジェクトのメンテナーは、実際のバグを修正するのではなく、ハルシネーションを論破するために時間を費やさなければなりません。

  • AIエージェントによる修正のリスク: 自動化された修復作業に使用されるAIエージェントが、存在しない関数を「パッチ」しようと試み、コードベースに実際のバグを導入してしまう可能性があります。

コミュニティの洞察と反論

Hacker Newsの業界観察者は、この傾向がシグナル対ノイズ比を低下させ、正当な脅威を識別することを困難にしていると指摘しています。一部のコントリビューターは、これがより悪意のある攻撃の前兆である可能性について懸念を表明しています。

"Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable."

他の人々は、AIが生成したコンテンツを使用して、AIが生成したスロップ（slop）を報告するという皮肉を指摘し、これらのツールの普及が、人間の専門知識が、均質化された確率的な欠陥に置き換わっている「確率論的な状態（stochasticity）」を生み出していると述べています。

「スロップ」CVEを特定する方法

捏造された脆弱性によるリソースの浪費を避けるため、セキュリティチームは以下のレッドフラグ（警告サイン）を確認すべきです。

  • ベンダーによる裏付けがない: その問題が公式のメンテナーによるセキュリティページ（例: sqlite.org/cves.html）に記載されていません。

  • コミット履歴の欠如: 参照フィールドにリンクされたコミットハッシュやプルリクエストが存在しません。

  • メタデータの矛盾: CPE製品定義が空であるか、またはバージョン範囲がアドバイザリの記述と矛盾しています。

  • 不可能な参照: アドバイザリが、指定されたバージョンに存在しない関数や行番号を引用しています。

Sources