AI・テクノロジー

AI捏造の偽CVEがNVD通過——SQLite脆弱性55件中54件が架空

JFrogの調査で、あるGitHubアカウントが投稿したCVEアドバイザリ55件のうち54件がLLMによる完全な捏造だったことが判明。存在しない関数、EOFを超えた行番号、動かないPoC——それでもCVSS 9.8 Criticalとして国家脆弱性データベースNVDを通過していました。

claude

• 8 min read
Share

AI捏造の偽CVEがNVD通過——SQLite脆弱性55件中54件が架空

CVSSスコア9.8、深刻度「Critical」。標的は世界で最も広く使われている組み込みデータベース、SQLite。任意コード実行につながるヒープのuse-after-free——この警告を突きつけられて平然としていられるエンジニアは、そう多くないはずです。その警告は、生成AIが書いた作り話でした。しかも米国のNVD（国家脆弱性データベース）を通過したうえで。

アドバイザリが参照している関数は、SQLiteのソースコードのどこにも見当たりませんでした。脆弱性そのものが存在しなかったのです。

2026年7月30日にJFrog Security Researchの研究者Afek Berger氏が公開した調査結果は、脆弱性管理という業界の土台に静かな亀裂が入っていることを示しました。あるGitHubアカウントが投稿した55件のCVEアドバイザリのうち、54件が大規模言語モデルによる完全な作り話だった——しかもその一部は正式なCVE番号を取得し、米国の国家脆弱性データベース（NVD）にCritical判定で収録されていたのです。

背景：CVEという「脆弱性の共通言語」はどう流れているか

事件の意味を掴むには、脆弱性情報がどこを通って手元に届くのかを押さえておく必要があります。

出発点は、MITREが統括するCNA（CVE採番機関）の体制です。報告された脆弱性にCVE番号が採番され、識別子として世界共通で使われます。次にNISTが運営するNVD（National Vulnerability Database）がCVSSスコアやCPE（影響を受ける製品の定義）を付与し、深刻度を判定します。この情報がGHSAなど各種フィードへ流れ、脆弱性スキャナ、SBOMツール、パッチ管理システム、企業のチケットシステムへと自動で伝播していく——というのが現在の標準的な流れです。

この仕組みは、NVDが「検証済みの信頼できるレイヤー」として機能することを暗黙の前提にしていました。かつてはNVDの専門家が全件にエンリッチメントを施していたのです。

その前提が崩れます。2024年2月、脆弱性報告の急増に押される形でNISTは深い分析を事実上停止。さらに2026年4月15日、NISTはNVDの全件分析を断念すると正式に発表しました。CISAのKEV掲載CVEや連邦重要ソフトウェアなど3カテゴリを優先し、それ以外は「未検査」として登録のみ行うリスクベースのトリアージ運用へ移行しています。

安全網が外れた状態のパイプラインに、生成AIが流し込まれた格好です。

何が起きたのか：SQLiteの偽CVE55件中54件が「AIの作り話」だった

発端は、2026年7月下旬に新規作成されたGitHubリポジトリ programmervuln/cveadvisory- でした。このアカウントは短期間に55件の脆弱性アドバイザリを立て続けに公開します。うち6件がSQLiteを標的にしたもので、いずれもメモリ破壊による任意コード実行という筋書きでした。深刻度は3件がCVSS 9.1以上のCritical、残る3件もHighです。

NVDはこれらを速やかに登録し、CISAのADP（Authorized Data Publisher）プログラムも深刻度の妥当性を認めました。脆弱性情報のパイプラインとしては、正規のルートを正規の手順で通過したことになります。

違和感に気づいたのがJFrogの研究チームでした。実際に検証してみると、報告内容は次々と崩れていきます。

  • 引用されているコードが、対象バージョンに存在しない、もしくは全く無関係なロジックだった
  • 添付されたPoC（実証コード）を実行してもクラッシュひとつ起きなかった
  • SQLite公式のアドバイザリページ（sqlite.org/cves.html）に一件も掲載されていなかった
  • 全アドバイザリを結合してGPTZeroにかけると、AI生成コンテンツの警告が出た

決定打となったのは、同一アカウントの55件を横断監査した結果です。54件が完全な捏造であり、残る1件だけが実在するバグでした。ただしその1件も、CVEメタデータは未検証のまま登録されていました。

技術的検証：JFrogはどうやって「存在しない」ことを証明したか

「脆弱性がある」ことを示すより「ない」ことを示すほうが難しいのが常です。JFrogは4段階の手順でこの困難を突破しました。

  1. 公式の sqlite/sqlite リポジトリをcloneし、対象タグ（version-3.41.0、3.51.2、3.51.3）をチェックアウトして実ソースと突き合わせる
  2. 環境汚染を避けるため、Dockerコンテナ内で公式リリースを隔離ビルドする
  3. AddressSanitizer（ASan）計装下で、各アドバイザリのPoC SQLを一字一句そのまま実行する
  4. NVDとGHSAのフィードからCPEパターンとメタデータを監査する

CVE-2026-51302（CVSS 9.8）：存在しない関数

sqlite3ReleaseTempReg() が残したダングリングポインタを exprComputeOperands() が参照する、という筋書きでした。しかし exprComputeOperands() はSQLite 3.41には存在しません。2025年半ばのコミット（e24f20a、280559b）で後から追加された関数です。さらに sqlite3ReleaseTempReg() はレジスタ番号を配列に戻すだけで、ヒープの解放を一切行いません。use-after-freeは設計上起こりようがないのです。

CVE-2026-51303（CVSS 9.8）：幽霊パッチ

「バージョン3.51.3で修正済み」と明記されていましたが、3.51.2と3.51.3の差分を取ると src/expr.c には変更が一行もありません。修正そのものが捏造でした。PoCに至っては不正なSQLで、パーサ段階で弾かれて実行ロジックにすら到達しません。

CVE-2026-51296（CVSS 7.5）：EOFを超えた行番号

json.c の3555行目と3575行目にバグがある、と具体的な行番号まで示していました。しかし3.41.0の json.c は全2706行しかありません。存在しない行を指していたわけです。

残る3件も同様です。存在しない関数、無関係な行番号、あるいは実在する関数でも引数の数が違う——揃って「実物を見ずに書かれた」痕跡が残っていました。なおCVE-2026-51302についてはRed Hatが当初10.0 Criticalを付与し、翌日には7.6 Highへ格下げしています。判定側も揺れていたわけです。

なぜNVDで止められなかったのか：身元確認なき入口と外れた安全網

問題は「AIが嘘をついた」ことではありません。嘘が制度の網をすり抜けてしまう構造のほうです。

まず入口。MITREの公開投稿フォームには、実質的な身元確認がありません。誰でも脆弱性の説明文を書き、CVSSスコアを提案できます。

次に検証層。前述のとおりNISTの安全網は外れ、CISAをはじめとするADPが穴を埋めようとしたものの、パイプラインは断片化し膨大なバックログを抱えたままです。今回はそのADPが深刻度を追認する側に回ってしまいました。

そして最大の欠陥は、この一連の流れのどこにも「PoCを提出せよ」「バグを再現して見せよ」という関門が存在しないことです。もっともらしい文章さえ書ければ、そのままGHSAへ、下流のデータベースへ、企業のスキャナへと流れていきます。

生成AIは、まさに「もっともらしい文章を大量に書く」ことに最適化された道具です。噛み合ってしまったわけです。

影響：AIがAIの嘘を追いかける悪循環

偽CVEの実害は、単なる情報のノイズにとどまりません。

直接的なコストは工数の浪費です。Critical判定のCVEが自動的に優先度最上位へ回り、チケットが自動起票される運用の組織では、存在しない脆弱性のために調査と説明の時間が費やされます。スキャナ経由で顧客から問い合わせが来れば、その対応工数も乗ります。

より厄介なのは、脆弱性トリアージをAIで自動化している環境です。JFrogはこの点を明確に警告しています。偽CVEに遭遇したAIエージェントは、存在しない関数を探し、ありもしない箇所にパッチを生成しようと試み、コードベースへ不要な変更を提案しかねません。AIが生み出した虚構を、別のAIが真に受けて実装に反映する——そんな循環が現実味を帯びてきます。

この構図は突然現れたものではありません。データ転送ライブラリのcurlは、AI生成の低品質な脆弱性報告が氾濫した結果、2026年1月末でバグバウンティ制度を終了しています。報道によれば報告件数は15倍に膨れ上がった一方で、本物の脆弱性は5倍にも届いていません。

これまでのAIスロップは、SNSのタイムラインや通販サイトの商品リストを汚す「うっとうしいもの」でした。捏造されたCVEは質が違います。セキュリティ業界が共有する信頼のインフラそのものを侵食するからです。

偽CVEの見分け方と実務対応

JFrogは、疑わしいCVEを見分けるための赤信号を4つ挙げています。

  • ベンダーの裏付けがない：メンテナ公式のセキュリティページに該当する記載がない
  • コミット履歴がない：参照欄にコミットハッシュやプルリクエストのリンクが張られていない
  • メタデータが矛盾している：CPEの製品定義が空、あるいはバージョン範囲がアドバイザリ本文と食い違う
  • 存在しないコードを参照している：対象バージョンにない関数名、ファイル末尾を超えた行番号

そのうえで、実務としては次の4点が推奨されています。

  1. 未検証・無名のソースが公開したばかりのCVEを盲信しない
  2. Criticalスコアが脆弱性の実態に見合っているか、自分の目で確かめる
  3. 自分の環境が本当にその影響範囲に入るのかを確認する
  4. 可能な限り、安全な環境でPoCを再現してみる

要するに、自動化された優先度付けを最終判断にしないということです。JFrogは今回の調査結果をGHSA・Red Hat・NVDへ正式に報告してレコードの修正を要請しており、報道によれば該当するCVEレコードは公開から4日で一斉に撤回されました。

よくある質問

SQLiteの偽CVE（CVE-2026-51302など）は本物なのか

いずれも本物ではありません。JFrogが公式リポジトリのソースコードと突き合わせ、Docker上でビルドしたバイナリにAddressSanitizerを効かせてPoCを実行した結果、報告された挙動は一件も再現しませんでした。SQLite公式のCVE一覧ページにも該当する記載はありません。

なぜ偽物なのにCVSS 9.8のCritical判定が付いたのか

MITREの投稿フォームには実質的な身元確認がなく、投稿者自身がCVSSスコアを提案できるためです。従来の検証層だったNVDは2024年2月に深い分析を停止し、2026年4月には全件分析の断念を正式発表しました。PoCの提出や再現確認を必須とする関門が、プロセス上どこにも存在しないことが根本的な原因です。

自分の組織で使っている脆弱性スキャナは信用できなくなるのか

スキャナそのものが壊れているわけではありませんが、上流のCVEデータが汚染されうる以上、スキャナの出力を無条件の真実として扱うのは危険です。ベンダー公式のセキュリティ情報との突き合わせ、参照欄のコミットハッシュの有無、CPEメタデータの整合性といった確認を挟むことで、大半の偽CVEは弾けます。

AIで脆弱性対応を自動化している場合、特に何に気をつけるべきか

AIエージェントが偽CVEを受け取ると、存在しない関数を探しに行き、ありもしない箇所へパッチを生成しようとする恐れがあります。自動修正を人間のレビューなしにマージしない、対象コードが実在するかを機械的に検証する工程を挟む、といった歯止めが必要です。

まとめ

55件中54件が捏造だったという数字は、それ自体が衝撃的です。しかし本当の問題は、その捏造が誰にも止められないまま国家脆弱性データベースへ到達したという事実のほうにあります。

CVE制度は、善意の報告者が正確な情報を上げてくることを前提に設計されていました。その前提を、もっともらしい文章を無限に生成できる道具が崩しつつあります。NISTが全件分析を諦めた今、検証の負荷は下流——つまり私たち利用者側へと押し出されました。

脆弱性情報を「与えられるもの」として消費する時代は、静かに終わりかけているのかもしれません。Criticalの4文字を見たら、まずソースを確かめる。それが必須の手順になります。

参考ソース

関連記事