SQLite の重大CVEは実在しない？AI生成の虚偽脆弱性が発見

JFrog のセキュリティ研究者が GitHubで公開されたSQLite脆弱性通知を検証したところ、6つのCVEが存在しない関数を引用し、無効な実証コード（PoC）を含む、AI生成の虚偽であることが判明した。NVDが「CRITICAL」に分類した複数のCVEが実在しない脆弱性だったもので、脆弱性検証プロセスの問題が露呈した。

GitHubのユーザー「programmervuln」が作成したリポジトリ（programmervuln/cveadvisory-）には、SQLite の重大脆弱性とされる複数の通知が掲載された。NVD はこれらをCRITICAL として登録し、CISA の ADP（脆弱性分析提供者）も同じ評価を下した。しかし JFrog が検証したところ、引用されたコードはそれらのバージョンに存在しないか無関係なロジックを参照していた。PoC ペイロードはクラッシュを引き起こさず、SQLiteの公式通知ページにも掲載されていないという。

検証対象のCVE

JFrog が詳細に分析した6つのCVEは以下の通りである。

• CVE-2026-51302 (CVSS 9.8 CRITICAL → Red Hatが後に 7.6 HIGH に格下げ)：exprComputeOperands() はSQLite 3.41には存在せず、2025年中盤に追加された。
• CVE-2026-51300 (CVSS 9.1 CRITICAL)：sqlite3ReleaseTempReg() はヒープ解放を伴わず、レジスタインデックスをリサイクルするだけである。
• CVE-2026-51303 (CVSS 9.8 CRITICAL)：SQLite 3.51.2 から 3.51.3 への差分では src/expr.c に全く変更がなく、引用された「パッチ」は完全に虚偽である。
• CVE-2026-51301：jsonBlobEdit() は version 3.41.0 に存在せず、後に JSONB 実装の一部として導入された。
• CVE-2026-51297 (CVSS 8.8 HIGH) および CVE-2026-51304 (CVSS 7.5 HIGH)：同様に、引用されたコード行や関数シグネチャが実在しない。

JFrog は公式の sqlite/sqlite リポジトリを clone し、Docker コンテナで隔離された環境でSQLiteリリースをコンパイルし、AddressSanitizer インストルメンテーションを用いて検証した。

AI生成コンテンツの特定

すべての通知をGptzero でテストしたところ、AI生成の疑いが極めて濃厚だった。当該GitHubアカウントが公開した55の通知全体を監査した結果、54件が完全に虚偽であり、わずか1件のみが実在する不具合を含んでいたが、その場合も未検証のCVEメタデータでラップされていたという。

CVE提出・検証プロセスの脆弱性

JFrog の指摘によれば、MITRE の公式フォームを通じたCVE提出は真の身元確認を欠いており、現在のシステムではいかなるステップにおいても実際の実証コードやバグ再現を要求していない。その結果、もっともらしい虚偽の通知が検証パイプラインをそのまま通過することができる。特に問題とされるのは、2024年2月以降、NIST がCVEの詳細な分析を事実上停止したことである。報告の大幅な増加により、従来は受信CVEを検証するセーフティネットが機能しなくなったという。

JFrog は正式な報告を GHSA、Red Hat、NVD に行った。

筆者の見立て

• 虚偽のCVEは、Critical脆弱性が自動的に優先される環境や脆弱性スコアに基づいてチケットが自動作成される環境では、実際の負担となる可能性を示唆している。
• AI を使用して脆弱性のトリアージと修復を自動化する環境では、この問題がさらに深刻になるとみられる。
• AIエージェントが虚偽のCVEに遭遇した場合、存在しないコードを基に脆弱な関数の特定、パッチの生成、変更の推奨を試みる可能性がある。
• その結果、セキュリティチーム がまったく誤った方向に導かれ、不要な変更が導入され、実際の脆弱性の修復に費やすべき時間が浪費されると解釈している。

この記事は元記事の事実のみに基づいて自動生成されました。

出典

JFrog, "SQLite Critical CVEs or LLM Slop?", https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ (MITRE、CISA、Red Hat の報道による)