SQLiteに存在しない関数を突いた偽CVE群、NVDでCritical掲載まで通りMITREが一括却下

TL;DR

---

JFrog Security Researchは2026年7月30日、SQLiteに対して公開された6件のCVEがすべて捏造だったとする調査結果を公開した。
CVEはソフトウェアの脆弱性に付く共通の識別番号で、6件はいずれも深刻度の共通指標CVSSで7.5から9.8、つまりHighからCriticalの評価つきで米国の脆弱性データベースNVDに掲載されていた。

SQLiteの作者Richard Hipp氏のもとには、信頼できるセキュリティ分析者から、この架空のCVE群について問い合わせるメールが届き始めていた。
JFrogの研究者Afek Berger氏が6件を検証したところ、どれも対象バージョンのソースコードと突き合わせた時点で崩れた。さらに報告元のGitHubアカウントを調べると、SQLite以外も含めた55件の報告のうち54件が捏造だった。実在するバグを含む残る1件も、CVEとしてのメタデータは検証されていない。

Hipp氏はこの件を受けて、公式フォーラムに「Fake CVEs against SQLite」というスレッドを立てている。
CVE番号を管理する米国の非営利組織MITREは7月31日に該当CVEを一括で却下したが、その過程でSQLite開発チームへの連絡は一度もなかった。

6件すべてが実在しないコードを指していた

問題の6件はCVE-2026-51296、51297、51300、51302、51303、51304。いずれもSQL文の処理やJSON関数にメモリ破壊系の欠陥があるという主張で、NVD掲載時のスコアは次のとおりだった。

CVE	掲載時CVSS	主張	JFrogが確認した矛盾
CVE-2026-51302	9.8 Critical	式評価でのuse-after-free	根拠に挙げた関数 exprComputeOperands() が対象の3.41系に存在しない。追加されたのは2025年半ば
CVE-2026-51303	9.8 Critical	3.51.3で修正済みの欠陥	3.51.2と3.51.3の差分に src/expr.c の変更が一切ない
CVE-2026-51300	9.1 Critical	メモリ破壊	根拠の行番号1012と1026は、実際にはコメントとメモリ確保の呼び出し
CVE-2026-51297	8.8 High	JSON処理の欠陥	根拠の関数 jsonBlobEdit() が対象の3.41.0に存在しない
CVE-2026-51296	7.5 High	json.cの3555〜3575行目の欠陥	3.41.0の json.c は全体で2706行しかない
CVE-2026-51304	7.5 High	メモリ破壊	記載された形の関数シグネチャが存在しない

use-after-freeは、解放済みのメモリを使い続けてしまう不具合で、悪用できればクラッシュや任意コード実行につながる。主張自体はもっともらしい類型ばかりだが、根拠として挙げられたコードが存在しなかった。

添付されていた再現用のSQL文を実際に流しても、クラッシュは1件も再現しなかった。
報告の文章をAI文章検出サービスのGPTZeroにかけると、AI生成コンテンツとみられる判定になった。JFrogはこの結果と内容の崩れ方を合わせて、一連の報告がLLMの生成したスロップ、つまり検証を欠いた低品質な量産物である可能性を指摘した。

報告元はGitHubの programmervuln というアカウントが作った cveadvisory- というリポジトリで、短期間に55件の「アドバイザリ」を公開していた。SQLiteの6件のほか、RAW画像処理ライブラリのlibrawとArduino向け音声ライブラリのESP32-audioI2Sに対する49件があり、実在するバグを含んでいた1件を除いて、こちらも捏造だった。

検証なしでCritical掲載まで通った

捏造の報告が採番からNVD掲載まで通った経路は次のとおりだ。

graph TD
    A["GitHubリポジトリに<br/>偽アドバイザリ55件"] --> B["MITREの申請フォーム<br/>提出者の自己申告制"]
    B --> C["CVE採番・公開"]
    C --> D["NVD掲載<br/>CVSS 7.5〜9.8"]
    C --> E["Red Hat評価<br/>一時10.0"]
    D --> F["脆弱性スキャナーが<br/>世界中で警告"]
    F --> G["JFrogがコードと照合<br/>54/55が捏造と判定"]
    G --> H["7月31日<br/>MITREが一括却下"]

CVEの採番は、MITREや各CNA（CVE採番機関）が受け付ける。自分のコードでないソフトウェアのCVEを扱う場合、採番側が報告を独自に再現検証する工程は基本的にない。OracleのエンジニアAlan Coopersmith氏はoss-securityメーリングリストで、この構造を「MITREをはじめ、自分たちが作っていないコードにCVEを採番するCNAの多くは性善説で運用されており、報告者が内容を検証済みであることを信頼している」と説明した。

その結果、存在しない関数を挙げた報告がそのまま採番され、NVDに7.5から9.8のスコアつきで載った。
Red HatはCVE-2026-51302に一時、CVSSの最大値である10.0を付けた。JFrogが調査中に再確認した時点では7.6のHighまで下げられていた。現在のRed Hatのページは、自社製品は影響を受けないこと、開発元のSQLiteが架空のCVEだと確認したこと、採番したCNAがRejectedにしたことを記載している。

NVDに載った番号は、世界中の脆弱性スキャナーやSCA（ソフトウェア構成分析）ツールがそのまま取り込む。
SQLiteはブラウザ、スマートフォン、組み込み機器まで広く入っているため、Criticalの警告が一斉に出て、冒頭の「いつ直るのか」という問い合わせにつながった。

Berger氏はThe Registerの取材に、この構造の非対称性を述べている。生成AIによって、もっともらしいアドバイザリを作るコストはほぼゼロまで下がった。一方で、それを検証するコストは変わらない。ソースコードを読み、対象バージョンをビルドし、再現手順を試す作業が1件ごとに必要で、リソースのある防御側でもすべての報告を人手で検証するのは成り立たない、という指摘だ。

SQLite公式は「AIの幻覚と見られる」と明記した

Hipp氏は7月29日、公式フォーラムで架空のCVEについての問い合わせが届いていることを明かした。
このスレッドによれば、SuSEは問題のCVE群をClaudeにかけて分析し、捏造という結論を得ていた。Hipp氏は「SQLiteに対する新しいCVEを見かけたら、まず偽物だと思ってよい」とまで書いている。

SQLite公式サイトの脆弱性ページも更新され、該当6件は「SQLiteのバグではない」という区分で一覧に載った。「再現不能で、AIの幻覚と見られる」としてJFrogの分析へリンクしている。

同ページはもともと、CVE全般への不信を隠していない。SQLiteの過去の脆弱性はすべて、攻撃者が任意のSQL文を実行できるか、細工したデータベースファイルを読み込ませられるかのどちらかを前提としており、この前提を満たす実アプリケーションは少ない、という立場だ。今回の件では、前提の誇張どころか、存在しない欠陥そのものが混じっていた。

8月4日のフォーラムへの返信でHipp氏は、却下までの過程でMITREからSQLite開発チームへの接触が一度もなかったことを確認している。
採番のときだけでなく、却下のときも、ベンダーへの確認はなかった。

却下までのタイムライン

日付（2026年）	出来事
7月27日	CVE-2026-51302などがNVDに掲載される
7月29日	Hipp氏が公式フォーラムにスレッドを立て、偽物と告知
7月30日	JFrogが調査結果を公開
7月31日	MITREが一括却下。NVDの該当レコードがRejectedになり、oss-securityで共有される
8月4日	Hipp氏がMITREからの接触が皆無だったことをフォーラムで確認

NVDの却下理由は「CNAによって取り下げられた。調査の結果、セキュリティ問題ではなかった」という一文で、掲載から却下まで4日だった。
一方、報告元のGitHubリポジトリは、8月5日時点でもまだ公開されたままだった。

偽CVEの背景にはNVDの未処理27,000件超がある

偽CVEがすり抜けた背景には、採番と検証を担う側の慢性的な過負荷がある。
米商務省監察官室（OIG）の2026年5月の報告書によると、NVDの未処理バックログは2024年6月初めの約13,000件から、2025年末には27,000件超まで増えた。同報告書は、運営元のNISTが戦略的な計画も果断な行動も欠いたまま、バックログの増大を許したと指摘している。CISA（米国のサイバーセキュリティ庁）などが付加情報の提供で補っているが、そのCISA由来のスコアが今回の偽CVEにも付いていた。

フォーラムの議論は、curl、Rust、Linuxカーネルといったプロジェクトが自らCNAになった経緯にも触れていた。
CNAになると、自分のプロジェクトのCVEを自分たちで採番・却下できるようになり、第三者による低品質な報告を通さずに済む。curlのDaniel Stenberg氏も、AI生成のバグ報告への対処を長年訴えてきた。

JFrogは防御側への推奨として、Criticalを見てもすぐパッチ作業に入らず、ベンダー公式のアドバイザリと突き合わせること、修正コミットが履歴に実在するかを確認すること、可能なら隔離環境で再現を試すことを挙げた。
今回の6件については、SQLite公式の脆弱性ページが「SQLiteのバグではない」の区分に載せ、NVDのレコードもRejectedになっている。