AI生成の偽CVEが脆弱性DBを汚染 55件中54件をJFrogが捏造と検証

JFrogがGitHubで公開された55件の脆弱性報告を検証し、54件がAI生成とみられる完全な捏造だったと2026年7月30日に発表した
存在しない関数の引用やファイル末尾を超える行番号などAI特有の痕跡が確認され、SQLite関連6件はNVDで最高評価まで受けていた
CVE登録に本人確認や再現検証が不要で、NISTの精査体制も2024年以降停止しており、公的DBの信頼性に構造的欠陥が露呈した

SQLiteの偽脆弱性が発覚

米セキュリティ企業のJFrogは2026年7月30日、データベースソフト「SQLite」に関する一連の脆弱性情報がいずれも実在しないと確認したと発表しました。問題となったのは、あるユーザーがGitHubのリポジトリで公開していた55件の脆弱性報告です。JFrogの調査チームがこれらを精査したところ、54件が完全な捏造だったと判明しました。

捏造の割合は98%を超えます。SQLite関連の報告は6件含まれており、その一部は米国立脆弱性データベース（NVD、National Vulnerability Database）に登録され、深刻度が最高の「クリティカル（緊急）」と評価されていました。Red Hatに至っては、共通脆弱性評価システム（CVSS、Common Vulnerability Scoring System）で最高値の10.0を付与していたといいます。

捏造を見抜いた4つの矛盾

JFrogは報告書の記述を実際のソースコードと突き合わせ、いくつもの矛盾を見つけました。まず、対象バージョンには存在しないはずの関数が、脆弱性の原因として引用されていました。さらに、指摘された箇所の行番号がファイルの末尾を超えており、そもそも参照できない位置を示していたのです。

報告に添付された実証コード（PoC、Proof of Concept）を動かしても、脆弱性なら起きるはずのクラッシュは発生しませんでした。加えて、これらの欠陥はSQLiteの公式サイトにいっさい掲載されていませんでした。存在しない関数への言及やファイル長を超える行番号は、コードを実際に読まずに文章を組み立てる生成AIが起こしやすい誤りであり、AIによる自動生成を強くうかがわせる痕跡です。

図に示すように、AIが生み出した偽情報は複数の段階を経て公的なデータベースに定着し、最終的に開発者の負担へと転嫁されていきます。

誰でもCVEを登録できる仕組み

今回の問題の根っこには、CVE（共通脆弱性識別子、Common Vulnerabilities and Exposures）の登録手続きの緩さがあります。CVEは脆弱性に通し番号を割り振る国際的な仕組みですが、登録の際に申請者の本人確認や、報告された脆弱性を実際に再現する検証が必須とされていません。つまり、もっともらしい体裁さえ整えれば、実在しない欠陥でも番号を得られてしまいます。

本来はNVDを運用する米国立標準技術研究所（NIST、National Institute of Standards and Technology）が登録内容を精査する役割を担っていました。ところがJFrogによると、NISTは2024年以降、詳細な分析を停止しています。チェック機能が働かないまま、AIが量産した偽情報が公的なデータベースへそのまま流れ込む構図です。