AIが生成した偽の脆弱性がCVEデータベースを汚染｜SQLite架空CVE-2026-51302事件・NVD/CISAが承認した経緯と防衛策【2026年8月最新】

2026年7月末、AIが生成したとみられる「実在しないSQLiteの脆弱性」6件が正式なCVE番号を取得し、NVD（米国国家脆弱性データベース）で最大CVSS 9.8「Critical」として公開されました。 起きたのは「SQLiteに深刻な脆弱性が見つかった」ではなく、脆弱性情報そのものが汚染されたという事件です。

セキュリティ企業JFrogの検証により、同一のGitHubアカウントが数日で投稿した55件のアドバイザリのうち54件が完全な捏造だったと判明し、MITREはこれらのCVEを一括で却下（REJECT）しました。SQLite公式サイトも該当CVEについて「再現不能であり、AIのハルシネーション（幻覚）とみられる」と明記しています。

本記事では、一次ソースに基づく事実と時系列、6件の捏造CVEを偽物と断定できた技術的根拠、公的パイプラインを4日間も通過してしまった構造的な理由、そして企業の脆弱性スキャナ・SLA・監査・SBOMに及ぶ実務影響と具体的な防衛策までを扱います。脆弱性管理・SOC・情報システム部門の担当者、OSSを組み込んで製品開発するエンジニア、SBOM/SCAツールの運用者、そして「AIが作った偽情報が公的データベースに載る」という新しいリスクを把握しておきたい経営・ガバナンス層に向けた内容です。

本件は現在も動いている事案のため、2026年8月上旬時点で確認できた事実と、まだ確定していない部分を分けて記載します。

問題の所在はSQLiteではなく、CVE登録パイプラインの検証不在

• SQLiteに脆弱性はなかった。 報告された関数の一部はそもそも対象バージョンに存在せず、引用された行番号はファイルの総行数を超えていた。
• それでも CVE-2026-51302 はNVDに掲載され、CVSS 9.8 Critical、Red Hatでは一時 10.0 として扱われた（のち7.6に引き下げ、最終的にRejected）。
• 原因は、CVE登録の過程のどこにも「本人確認」「再現検証」「PoC提出」が必須要件として存在しないこと。JFrogは「MITREの公開フォーム経由の申請プロセスには実質的な身元確認がない」と指摘している。
• 生成AIによってもっともらしい偽アドバイザリを作るコストはほぼゼロになった一方、それを検証するコストは変わっていない。この非対称性が事件の本質。
• 企業側の対応は「新規CVEを鵜呑みにしない」に尽きる。具体的にはベンダー公式ページ → 修正コミット → 自環境への到達性 → 対応判断の4段階を挟む運用に切り替える必要がある。

AIが生成したもっともらしい虚偽が権威ある文書に混入する構図は、KPMGがAI生成の偽引用で報告書を撤回した事案とまったく同じ構造です。今回はその舞台が、世界中のセキュリティ運用が依存する公的データベースだった、という点で影響範囲が桁違いに大きくなっています。

何が起きたのか：数日で55件、うち54件が捏造

出典: JFrog 公式サイト (jfrog.com)

2026年7月下旬、新規に作成されたGitHubリポジトリ programmervuln/cveadvisory- から、数日間で55件の脆弱性アドバイザリが公開されました。 対象はSQLite（6件）のほか、RAW画像処理ライブラリ libraw、Arduino向け音声デコードライブラリ ESP32-audioI2S などです。

JFrog Security Researchのブログ「SQLite Critical CVEs or LLM Slop?」（2026年7月30日、Afek Berger氏）による監査の結果、55件のうち54件が完全な捏造でした。残る1件のみ実在するバグでしたが、それも未検証のCVEメタデータで包まれていたとされています。

ここで押さえておきたいのが「AI slop（AIスロップ）」という言葉です。LLMが生成した、もっともらしいが中身のない大量生成コンテンツを指し、セキュリティ領域では「技術用語・関数名・PoCらしきコードが並ぶのに、実在しない脆弱性報告」を意味します。従来のスパム的な虚偽報告と違い、専門家でも一読では見抜けない密度を持っているのが厄介な点です。

JFrogがアドバイザリ本文をAI検出ツール GPTZero にかけたところ、全体でAI生成の警告が出たと報告されています。ただしAI検出ツール自体に誤判定リスクがあるため、これは補助的な材料にすぎません。技術的な決め手は、存在しない関数や行数超過といった実コードとの突き合わせでした。

時系列：掲載から却下までわずか4日

注目すべきは、CVE-2026-51302 が公開されてから却下されるまで4日間あったという事実です。その4日間、NVDやGHSAをフィードとする世界中の脆弱性スキャナは、存在しない脆弱性を「Critical」として自動的に検出し得ました。

捏造された6件のSQLite CVEと、偽物と断定できた根拠

JFrogの検証で決定的だったのは、報告された関数や行番号が対象バージョンのソースコードと一致しなかったことです。 抽象的な「怪しい」ではなく、コードを開けば誰でも確認できるレベルの矛盾でした。

興味深いのは、6件すべてが UAF（Use After Free／解放済みメモリの使用） を騙っている点です。UAFはCの実装で実際に頻出する脆弱性タイプであり、「いかにもありそう」に見えます。IPAのJVN iPediaでも2026年第2四半期に最も多く登録された脆弱性タイプは CWE-416（Use After Free）で749件でした。最も件数が多いカテゴリを模倣すれば、統計的に自然に見える——これは公式見解ではなく本記事による読み解きですが、AI生成コンテンツが「平均的にもっともらしいもの」を出力する性質と整合します。

その他49件は libraw と ESP32-audioI2S に対する主張で、こちらも偽物とされています（両プロジェクト側の対応状況は2026年8月上旬時点で未確認）。

SQLite開発陣の反応：「新しいSQLiteのCVEを見たら偽物と考えてよい」

SQLite作者のD. Richard Hipp氏は、7月29日に公式フォーラムへ「Fake CVEs against SQLite」を投稿し、強い調子でCVEプロセスを批判しました。 要旨は次の通りです。

• 無作為に確認したが、有効なものは1件も見つかっていない
• MITREは検証なしに誰からでもCVEを受け付けているようだ
• 当面、新しいSQLiteのCVEを見たら偽物と考えてよい

さらに8月4日の続報では、MITREがSQLite開発者に一度も連絡していない（CNAルール上の問題があるとの指摘）こと、各方面の指摘を受けて偽CVEが取り下げられたことに触れています。

SQLite公式の脆弱性ページ（sqlite.org/cves.html）は現在、CVE-2026-51296〜CVE-2026-51304 について「再現不能であり、AIのハルシネーションとみられる（They appear to be AI hallucinations）」と明記し、JFrogの解析へのリンクを掲載しています。

ここで構造的に重要なのは、SQLiteは自身がCNA（CVE Numbering Authority＝CVE番号を採番する権限を持つ組織）ではないという点です。そのため、第三者が自プロジェクトについて採番したCVEを止める手段がありませんでした。curl（2024年）、Rust（2025年）、Linuxカーネル（2026年）が相次いでCNA化したのは、まさにこのノイズを自プロジェクト側で統制するためだと、フォーラムでも議論されています。

なお、SQLiteチームはこの事件以前から、CVEに対して一貫して懐疑的な立場を公表しています。「SQLiteに関するCVEは、あなたのSQLiteの使い方には当てはまらない可能性が高い」「過去の脆弱性はすべて『攻撃者が任意のSQL文を実行できる』か『攻撃者が細工したDBファイルをアプリに開かせられる』のいずれかが前提であり、現実のアプリでこの前提を満たすものはほとんどない」といった指摘です。今回の事件は、その懐疑がもっとも極端な形で正当化された格好になりました。

なぜNVDとCISAの承認まで通ってしまったのか

出典: FIRST 公式サイト CVSS ページ (first.org/cvss)

答えは単純で、CVE登録パイプラインのどの段階にも「その脆弱性が実在するか」を確かめる必須の関門がないからです。 各段階で誰が何を見ているかを整理すると、穴の位置がはっきりします。

JFrogは「今日のシステムのどのステップも、PoCやバグの再現を実際には要求していない。だからもっともらしく聞こえる偽アドバイザリはパイプラインをすり抜け、GitHub Security Advisories、下流データベース、企業スキャナにまで到達する」と結論づけています。The Registerも、MITREおよび自社で開発していないコードにCVEを採番する大半のCNAが honor system（性善説）で運用されており、MITREには報告された問題を再現する設備がないと報じています。

そしてもう一つ厄介なのが、④のCISA-ADPが「権威の印章」として機能してしまう点です。CVSSスコアが公的機関によって付与されると、下流のツールと担当者はそれを「審査を通った証拠」として受け取ります。実際には、スコアは記述内容が正しい前提で機械的に計算されただけであり、実在性の保証ではありません。

動機は不明。「攻撃」と断定すべきではない

投稿者の身元・意図は2026年8月上旬時点で確認されていません。JFrogは推測として「偽の実績でセキュリティリサーチャーとしての経歴を水増しする狙い」「自動CVE検出ツールが何を脆弱性としてフラグするかに影響を与えるデータポイズニング的な狙い」を挙げていますが、いずれも確定していません。意図的なサプライチェーン攻撃と断定する報道は現時点では根拠が不足しています。

一方で、動機が悪意でなくても結果は同じです。「悪意ある攻撃者でなくても、生成AIを使えば公的データベースを汚染できてしまう」ことが実証された、というのが今回の教訓です。

背景：NVDのバックログとCVEプログラム自体の揺らぎ

出典: NIST 公式サイト (nist.gov)

「実在するCVEなら、NISTが分析してスコアを付けてくれる」という前提は、すでに崩れています。 これは今回の事件を理解するうえで欠かせない前提条件です。

2026年4月15日、NISTは公式にNVDの運用方針を変更しました。公表された背景と内容は次の通りです。

• CVE提出数は2020〜2025年で263%増。2025年は約42,000件をenrich（前年比+45%）したが処理が追いつかない
• 2026年3月1日以前に公開され未分析のCVEは「Not Scheduled（予定なし）」へ移動し、事実上バックログ解消を断念
• 今後は CISA KEV掲載・連邦政府利用ソフト・大統領令14028の「critical software」 を優先してenrichする方式へ
• CNAがスコアを付与済みの場合、NISTによる重複スコアリングは原則廃止

未処理CVEは2024年後半の17,000件から2025年末に27,000件超（米商務省監察官報告、2026年5月公表）、2026年初頭には30,000件超に達したとされ、監察官報告はNISTの「戦略的計画と決断力の欠如」を指摘しています。

つまり、かつて最後の砦だったNVDの手動レビューが、AI slopが押し寄せるタイミングで機能低下していたわけです。

さらにCVEプログラム自体のガバナンスも安定しているとは言えません。2025年4月15日、MITREはCISAとの契約失効を警告し、業界の反発を受けてCISAが11か月の延長を土壇場で執行、2026年3月まで資金を確保しました（それ以降の契約状況は本記事執筆時点で未確認）。CVE理事会メンバーからは「資金は依然として米国政府一本」「CVEプログラムはコミュニティなしでは何でもない。ただの契約だ」といった危機感が表明されており、EUなどが代替の脆弱性データベース（EUVD等）を立ち上げる動きも進んでいます。

前哨戦だったcurl：AI slopはまず報告窓口を壊した

出典: GitHub 公式サイト (github.com)

今回の事件は突然起きたわけではなく、AI slopがOSSの報告窓口を先に壊していた流れの延長線上にあります。 その代表例がcurlです。

• curlは2019年4月からHackerOneでバグバウンティを運用
• 2025年半ばまでに提出の約20%がAI slop（開発者Daniel Stenberg氏）。「AI slopはスパムには見えない。技術用語を使い、具体的な関数名やコードパスを参照し、もっともらしい攻撃シナリオを描く」
• 実際に脆弱性と確認された割合は15%超 → 5%未満に低下。7人のボランティアチームが1件ごとに数時間を浪費
• 2026年1月の最初の21日間で20件の提出、うち7件が16時間の間に集中
• 2026年1月31日、curlはバグバウンティを終了。2026年2月1日以降、セキュリティ報告はGitHub経由に一本化し報奨金は廃止

GitHub側でも、シニアセキュリティマネージャが「直近3か月で報告が224%増。個人的に見たことのない数字」「レポートの品質は極めて大きな懸念」とコメントしています。

報告窓口（バグバウンティ）→ CVEデータベース本体という順で汚染が進んだ、と捉えると流れが理解しやすくなります。AIが生成したコードや報告をレビューする負荷の問題は、開発現場でも同じ形で表面化しています（AIコーディングのセキュリティリスクも参照）。

企業への実務影響：スキャナ・SLA・監査・SBOM

偽CVEが「4日で却下されたから実害なし」とは限りません。 企業の脆弱性管理は自動化されているため、その4日間に副作用が波及します。

1. スキャナ／SCAツールの自動アラート

NVDやGHSAをフィードとするツールは、偽CVEを「Critical」として自動検出します。「Criticalは◯時間以内に対応」というSLAを持つ組織では、存在しない脆弱性のために緊急対応が発動します。深夜のエスカレーション、緊急パッチ会議、顧客への影響報告——コストはすべて実在します。

2. コンプライアンスとの衝突

PCI DSSなど「Critical CVEは期限内にパッチ適用」を求める基準と、「そもそも修正が存在しない偽CVE」が衝突します。是正のしようがない指摘が監査記録に残り、説明対応が必要になります。

3. AIによる自動トリアージの再帰リスク

これが最も新しく、最も注意すべき点です。LLMエージェントがCVEフィードを読み、自動でチケット起票やパッチ適用まで行う運用では、AIが生成した偽CVEをAIが処理する構図になります。人間が一度も原典に当たらないまま、偽情報が社内システムに定着しかねません。エージェントに権限を渡す際の設計原則はAIエージェントのセキュリティガイドで整理しています。

4. REJECT後の残留リスク

NVDはREJECTを静かに反映するだけで、個別に通知はしません。一度掲載されたCVE IDは、キャッシュ、ミラーDB、社内SBOMレポート、過去の監査資料に残り、却下後も長く参照され得ます。「REJECT/DISPUTEDになったCVEを定期的に再照会する」プロセスを持っていない組織は、幽霊CVEを抱え続けます。

偽CVEを見抜く4つのレッドフラグ

JFrogが示した確認ポイントは、専門的な逆アセンブルを必要としない、誰でも実行できる内容です。

補助シグナルとして、アドバイザリ本文をAI検出ツールにかけて生成物判定を見る方法もあります。ただしAI検出ツール自体に誤判定リスクがあるため、単独の判断根拠にはせず、あくまで補助材料に留めてください。

実務上、最もコストパフォーマンスが高いのは ①ベンダー公式ページの確認 です。今回の6件も、sqlite.org を開くだけで「公式に記載がない」ことが数分でわかりました。

今日からできる防衛策：新規Critical CVEの判定フロー

「Criticalが出たら即パッチ」を、「Criticalが出たら4段階で判定」に変えるのが最小限の対策です。 JFrogが防御側に推奨している内容を、実務フローに落とすと次のようになります。

ステップ1：ベンダー公式で裏取りする

開発元の公式セキュリティページ・リリースノート・フォーラムに該当CVEの記載があるか確認する。記載がない、あるいは公式が否定している場合は、この時点で対応を保留する。

ステップ2：修正コミットを確認する

修正パッチが実在するか、対象ファイルに実際の変更が入っているかを確認する。「修正されたはずのファイルに差分がない」場合、報告自体が捏造である可能性が高い。

ステップ3：自環境への到達性を確認する

CVEが本物でも、自社の使い方で攻撃条件が成立するとは限りません。攻撃前提（任意のSQL実行が可能か、外部由来のファイルを読ませているか等）が自社構成で成立するかを確認する。

ステップ4：対応を判断する

①〜③を踏まえ、緊急パッチ／計画パッチ／対応不要（記録のみ）を決定する。判断根拠を記録として残すことで、監査時に「なぜ対応しなかったか」を説明できます。

これに加えて、脆弱性管理の運用ルールへ次の項目を追加することを推奨します。

• 新規CVEの一次判定に「ベンダー公式ページに記載があるか」を必須ステップとして組み込む
• REJECT/DISPUTED状態のCVEを定期再照会するプロセスを設ける（NVDからの通知はない）
• 社内SBOM・スキャナのCVEキャッシュを、REJECT反映のため定期的に再同期する
• CVEフィードを読むAIエージェントには必ず公式ソース照合を挟み、人間の最終承認を残す
• 可能な範囲で、隔離環境でPoCを実行して再現を試みる
• OSSを提供する側であれば、CNA取得を検討する（curl・Rust・Linuxカーネルの前例）

なお、AIをセキュリティ運用の敵として捉える必要はありません。脆弱性の検出・パッチ提案を支援するAI側の進化も同時に進んでおり（OpenAI DaybreakやGPT-5.5-Cyberなど）、実際にAIが関与したゼロデイ脆弱性の悪用事例も報告されています。要は、AIの出力を検証なしに信頼するかどうかが分岐点です。業界全体でのAI活用状況はサイバーセキュリティ業界のAI活用で整理しています。

日本の脆弱性管理にとっての意味

出典: IPA 独立行政法人情報処理推進機構 公式サイト (ipa.go.jp)

日本企業の多くもNVDやJVN iPediaを起点に脆弱性管理を回しているため、上流の汚染はそのまま国内の運用工数に跳ね返ります。

• IPAのJVN iPediaは、2026年第2四半期（4〜6月）に13,131件を登録し、累計290,167件。2026年登録23,912件のうちアプリケーション関連が17,695件（約74.0%）
• 同四半期に最多だった脆弱性タイプは CWE-416（Use After Free）で749件。今回の偽CVE群がすべてUAFを騙っていたことと符合する
• IPA「情報セキュリティ10大脅威 2026」では、「AIの利用をめぐるサイバーリスク」が組織向け3位に初選出
• 2026年第2四半期のJVN iPedia登録では、AIツール自体の脆弱性登録も増加傾向にあると報じられている

日本語の脆弱性情報は英語の一次情報より遅れて流通することが多く、上流でREJECTされた情報が国内のミラーや社内資料に残りやすいという構造もあります。「英語の一次ソース（ベンダー公式・NVD原本）を必ず確認する」運用が、そのまま防衛策になります。

生成AIそのものが業務にもたらすリスク全体像は生成AIのセキュリティ・ガバナンス解説に、AIが予期しない振る舞いを見せた事例はAIエージェントの欺瞞的挙動に関する研究にまとめています。

こんな組織は特に注意／影響が限定的な組織

同じ事件でも、運用の作り方によって被害の大きさはまったく変わります。

特に注意が必要な組織

• CVSSスコアだけで対応優先度を機械的に決めている：スコアの真正性が検証されていない現実と噛み合わない
• 「Criticalは◯時間以内」の厳格なSLAを持つ：偽CVEでも緊急対応が発動し、リソースを消耗する
• 脆弱性トリアージをAIエージェントに任せている／任せようとしている：AI生成の偽情報をAIが処理する再帰が起きる
• OSSを多数組み込んだ製品を提供している：SBOM上の依存が多いほど、偽CVEに当たる確率が上がる
• 監査・認証対応でCVE対応記録の提出が必要：是正できない指摘が残ると説明コストが発生する
• CNAを持たないOSSプロジェクトのメンテナ：自プロジェクトについて第三者が採番したCVEを止める手段がない

影響が相対的に限定的な組織

• ベンダーの公式アドバイザリを一次ソースとして運用し、NVDは参考にとどめている
• 到達性分析（自環境で攻撃条件が成立するかの確認）を対応判断に組み込んでいる
• 依存OSSが少なく、更新も自社管理下で完結している
• 商用サポート付きディストリビューション（ベンダーが独自に検証・分類する体制）を利用している

ただし後者でも「安全」ではありません。今回、Red Hatですら一時的にCVSS 10.0を付与していました（のち7.6に引き下げ、最終的にRejectedと「SQLiteの上流開発者が架空と確認」「Red Hat製品には影響しない」を明記）。どこか一箇所を信頼して思考停止するのではなく、複数の情報源を突き合わせる姿勢が現実的な解になります。

よくある質問（FAQ）

Q. 結局、SQLiteに脆弱性はあったのですか？

A. ありません。問題となった6件（CVE-2026-51296〜51304の一部）はいずれも実在しない脆弱性で、SQLite公式サイトも「再現不能であり、AIのハルシネーションとみられる」と明記しています。報告された関数の一部は対象バージョンに存在せず、引用行番号がファイルの総行数を超えているものもありました。

Q. すでに偽CVEに対応してパッチを当ててしまいました。危険ですか？

A. 一般に、SQLiteなどのOSSを新しい安定版に更新すること自体に問題はありません。ただし、緊急変更としてリリース手順を省略した場合や、回避策として設定を変更した場合は、その変更が今も必要かを見直すことをおすすめします。「存在しない脆弱性への対処が恒久的な制約として残る」ことが実際のリスクです。

Q. 「AIが生成した」というのは確定した事実ですか？

A. 厳密には推定です。根拠はAI検出ツールによる判定と、実在しない関数・行数超過といった典型的なハルシネーション特徴であり、JFrog自身も「AI生成のように見える（seemed AI generated）」という表現を使っています。投稿者の身元・意図も2026年8月上旬時点で確認されていません。

Q. なぜMITREはこんな簡単に採番してしまうのですか？

A. MITREおよび自社開発でないコードにCVEを採番する多くのCNAは、報告者が情報を検証済みであることを信頼する honor system で運用されており、報告された問題を再現する設備を持っていないと報じられています。制度としてPoCや再現検証を必須にしていないことが、今回の通過を許した直接の原因です。

Q. 今後、同じことがまた起きますか？

A. 起きる可能性は高いと考えるのが現実的です。生成AIによる偽アドバイザリの作成コストはほぼゼロである一方、検証コストは変わっていません。curlのバグバウンティ終了（2026年1月）から今回のCVE汚染までの流れを見る限り、制度側の仕組みが変わらない限り同種の事案は繰り返されると見るべきです。

Q. 自社がOSSを公開している場合、何ができますか？

A. 有力な選択肢はCNA取得です。CNAになれば自プロジェクトのCVE採番を自分たちで統制でき、第三者による無検証の採番を防ぎやすくなります。curl（2024年）、Rust（2025年）、Linuxカーネル（2026年）が相次いでCNA化したのは、まさにこのノイズ統制のためだと説明されています。取得には運用体制が必要なため、リソースと相談のうえ検討してください。

Q. AIに脆弱性トリアージを任せるのはやめるべきですか？

A. 全面禁止する必要はありませんが、AIの判断を最終決定にしないことが前提です。CVEフィードを読むエージェントには、必ずベンダー公式ページとの照合を組み込み、対応・非対応の最終判断は人間が行う設計にしてください。

まとめ

今回のSQLite偽CVE事件は、「AIが嘘をつく」問題ではなく、「AIが作った嘘を止める仕組みが公的インフラ側になかった」問題です。

• AI生成とみられる実在しないSQLite脆弱性6件がCVE番号を取得し、NVDで最大CVSS 9.8 Criticalとして掲載された
• JFrogの検証で、同一アカウントの55件中54件が完全な捏造と判明。MITREが一括却下し、SQLite公式は「AIのハルシネーションとみられる」と明記
• 通過を許したのは、申請時の本人確認・再現検証・PoC提出がどの段階でも必須でないという構造的欠陥
• 背景には、2026年4月に方針転換したNVDのバックログ問題と、CVEプログラム自体の資金・ガバナンスの不安定さがある
• 企業側の対策は、ベンダー公式 → 修正コミット → 到達性 → 対応判断の4段階判定と、REJECT状態の定期再照会
• AIにトリアージを任せる運用ほど、AI生成の偽情報を素通りさせるリスクが高い

一次ソースに当たること、公式に確認すること——結論はきわめて古典的です。ただし、生成AIによって偽情報の生産量が跳ね上がった以上、この古典的な作法をどこまで運用として自動化・制度化できるかが分かれ目になります。関連するリスク整理として、生成AIのセキュリティ・ガバナンス解説、AIエージェントのセキュリティガイド、KPMGのAIハルシネーション報告書撤回事案もあわせてご覧ください。

主な参照元：JFrog Security Research「SQLite Critical CVEs or LLM Slop?」／SQLite公式フォーラム「Fake CVEs against SQLite」／SQLite公式「Vulnerabilities」／NVD「CVE-2026-51302 Detail」／Red Hat Customer Portal／NIST「NIST Updates NVD Operations to Address Record CVE Growth」／IPA「JVN iPedia 登録状況 2026年第2四半期」「情報セキュリティ10大脅威 2026」／The Register／ITmedia NEWS ほか