「脆弱性データベース(NVD)に載っているCVEは、ちゃんと検証されてるんじゃないでしゅか?」
「AIが偽の脆弱性情報を量産して公式DBに登録されてるって……信じてパッチ対応してたら大変でしゅよ!」
NVDに載ったCVEにCVSSスコアまで付いてたら、本物だと思うでしゅよ?まさか捏造なんて考えないでしゅよ……
それが問題の核心だな。CVEの提出には実質的な本人確認も技術検証も義務付けられていない。AIで量産された捏造CVEが公式DBに入り込む構造が生まれている
セキュリティ企業JFrogは2026年7月30日、あるGitHubリポジトリが短期間で投稿した55件のCVEのうち54件が完全な捏造だったと報告した。
SQLite関連の「CVE-2026-51302」はNVDに登録され、Red Hatが当初CVSSスコア10.0(最高値)を付与するまでに至った。
JFrogによる技術検証で存在しないコードへの参照や動作しないPoCなど多数の矛盾が確認され、AI生成コンテンツ検出ツールによる分析でもAI生成と判定された。
- 1つのGitHubリポジトリが短期間に投稿した55件のCVEのうち54件は捏造で、SQLite関連のCVEがNVDにCVSSスコア付きで登録されていた
- SQLiteの「CVSS 10.0緊急脆弱性」は存在しない関数への参照・失敗するPoCで構成された完全な捏造
- 2024年2月以降NISTの精査体制が変わり、CVEの「検証なし」登録が事実上可能になっている
組織が存在しない脆弱性への対応に追われることは、セキュリティリソースの深刻な浪費につながる。CVEへの盲目的な信頼を今こそ見直すときだ。
目次
何が起きたのか——55件中54件が捏造のCVEがNVDに登録
JFrogのセキュリティ研究チームは、GitHubリポジトリ「programmervuln/cveadvisory-」が短期間で投稿した55件のCVEを精査した。
SQLite関連のCVEを中心にNVDに掲載され一部にはCISAが追加情報(エンリッチメント)を付与していたが、JFrogの広範な監査で54件が完全な捏造だと判明した。
SQLiteの「CVSS 10.0」は何が問題だったのか
CVE-2026-51302はSQLite 3.41に影響するUse-After-Free(UAF)脆弱性として登録され、Red Hatが当初CVSS 10.0(最高値)のスコアを付与した。
JFrogが技術的検証を行った結果、以下の問題が確認された。
| 検証項目 | 結果 |
|---|
| 報告に記載された関数「exprComputeOperands()」の存在 | SQLite 3.41には存在しない(2025年中盤に追加された関数) |
| 「sqlite3ReleaseTempReg()」によるUAF発生可能性 | 設計上UAFは不可能で、報告の前提が誤り |
| 提供されたPoCの実行結果 | クラッシュは発生せず正常完了 |
| SQLite公式サイトへの記載 | 掲載なし |
AI生成コンテンツ検出ツール(Gptzero)による分析でも勧告文書はAI生成と判定された。
NVDの公式ページでは、CVE-2026-51302は2026年7月31日にRejectedとなり、CVSSスコアはN/Aとなっている。
CVE登録の構造的問題——なぜ捏造が公式DBに入り込めるのか
今回の事案は、偽の脆弱性情報が公式データベースに入り込める構造的な問題を浮き彫りにしている。
CVE提出はMITREの公開フォーム経由で行われ、実質的な本人確認や再現検証は義務付けられていない。
NISTの精査停止が生んだ「空白」——CISAが補完できない規模
2024年2月以降、NISTは膨大な脆弱性報告の増加に対処しきれなくなり、NVDでの深い手動分析を事実上停止した。
CISAなどの認定データパブリッシャー(ADP)が補完を担うが、今回のようにCVSSスコア付きで捏造CVEが通過してしまう事態が起きた。
- CVE登録フォームでは脆弱性種別・ベンダー名・製品名とバージョンなどが必要だが、技術的証拠の検証義務はない
- NISTの精査停止後、CISAが補完しているが完全には対応できていない
- AI生成ツールを使えば大量のもっともらしい脆弱性文書を短時間で生成できる
NVDに登録されてCVSSスコアまで付いてたら、普通に信じてしまうでしゅよ!どうやって見分けるでしゅか?
ベンダー公式サイトで言及があるか、PoCが実際に動くか、報告者の過去実績があるかを確認することだ。高いCVSSスコアは信頼性の証明にはならない
まとめ——公式CVEも盲信せず個別検証が必要な時代
JFrogは「新規公開のCVEを無検証で信頼しないこと」と強く呼びかけている。
存在しない脆弱性への対応にリソースを割くことは、本物の脅威への対応を遅らせることにもなる。
具体的な検証ポイントは以下のとおりだ。
- 公式ベンダーのセキュリティアドバイザリで言及されているか確認する(SQLite公式サイトに掲載がなければ要注意)
- 提供されたPoC(概念実証)を安全な検証環境で再現テストする
- 過去に実績のない新規アカウントからの報告は特に慎重に扱う
NVDに載ってても疑ってかかる必要があるでしゅか。CVEの信頼性確認が脆弱性管理の一部になってきたでしゅね……
ふふふ、それが現代のセキュリティ担当者に求められる力だな。AIが人間の作業を模倣できる時代、情報の一次確認能力がますます重要になってくる