SQLiteに存在しない脆弱性が「Critical」判定された背景—AIが生成した偽情報か？

AI生成と疑われるSQLiteの「偽」脆弱性情報

ここ数日、GitHubリポジトリ「programmervuln/cveadvisory-」において、SQLiteに関する多数の脆弱性アドバイザリが公開されました。これらのアドバイザリは、NVD（National Vulnerability Database）によって一時的に「Critical」と評価され、CISAのADP（Automated Data Processing）もこれを追認したとされています。

しかし、JFrogのセキュリティ研究者たちが検証に乗り出したところ、その主張の信憑性が疑わしいことが明らかになりました。(出典)

公開されたSQLiteの脆弱性は、実際には存在しないAI生成の偽情報である可能性が高い

具体的には、引用されたコードが指定されたバージョンに存在しない、または無関係なロジックを参照しているといった問題が見つかっています。さらに、PoC（Proof of Concept）が動作せず、SQLiteの公式アドバイザリページにもこれらのCVEが記載されていない点も、その信頼性を大きく損なう要因となっています。

GPTZeroによるテストでは、このリポジトリ内のすべてのアドバイザリがAI生成コンテンツであると判定されたとのことで、非常に衝撃的です。個人的には、AIがここまで巧妙に偽の情報を生成し、それが公的な機関に一時的にせよ認識されてしまうという事実に、開発者として警鐘を鳴らす必要があると感じました。

影響と検証結果—なぜ「Critical」とされたのか

今回の件で特に注目すべきは、一部の「偽」CVEが一時的に高いCVSSスコア（Severity Score）を割り当てられたことです。例えば、CVE-2026-51302は当初Red HatによってCVSS 10.0の「Critical」と評価されましたが、その後にCVSS 7.6の「High」にダウングレードされています。これらは、AIによって生成されたと疑われる脆弱性情報が、セキュリティコミュニティに与える影響の大きさを物語っています。

JFrogの研究者たちは、これらの報告を徹底的に検証するために、以下のテストワークフローを確立しました。(出典)

• ソースコード検査: 公式のsqlite/sqliteリポジトリをクローンし、対象となるタグ（version-3.41.0、version-3.51.2、version-3.51.3）で実際のソースコードと報告された脆弱性を比較。
• クリーンな環境でのビルド: 隔離されたDockerコンテナ内で公式SQLiteリリースをコンパイルし、環境汚染を防止。
• PoC実行: 各アドバイザリのPoC SQLステートメントをAddressSanitizer（ASan）計装下のコンパイル済みSQLiteバイナリに入力し、メモリバグを検出。
• NVDとメタデータの監査: NVDおよびGHSAフィード全体でCPEパターンとアドバイザリメタデータを評価し、追跡の正確性をクロスチェック。

これらの厳密な検証の結果、報告された脆弱性がいずれも存在しないことが確認されました。例えば、CVE-2026-51302で指摘されたexprComputeOperands()関数はSQLite 3.41には存在せず、2025年半ばにe24f20a、280559bのコミットで追加されたものであることが判明しています。

これは、AIが生成した情報が、リリース時期や関数存在の事実関係を無視している可能性を示唆しています。個人的には、普段Claude Codeにコードを書いてもらっている身として、AIが自信満々に嘘をつく「ハルシネーション」のリスクを改めて強く意識させられました。

AI生成情報の信頼性と今後の対策

今回のSQLiteの件は、AIが生成する情報の「完璧な嘘」が、いかに現実のシステムや人々に影響を与えうるかを示す典型的な事例と言えるでしょう。NVDやCISAのような信頼できる機関が、一時的にAIによる偽情報を真実と認識してしまった事実は、AI時代における情報検証の難しさを浮き彫りにしています。

特に、AI技術が進化し、より巧妙な偽情報（ディープフェイクやハルシネーション）を生成できるようになる中で、開発者やセキュリティ担当者は、情報の信頼性を多角的に検証するスキルがこれまで以上に求められると感じます。個人的には、このような状況でオープンソースプロジェクトの公式アドバイザリページがいかに重要か、改めて認識させられました。常に公式情報を最優先で確認することが、自身やプロダクトを守る上で不可欠だと感じます。