SQLiteに存在するとされた6件の脆弱性が、CVEレコードの公開から4日で一斉に撤回された。CISAの補完レイヤーはその間、各レコードにCVSS 7.5〜9.8と「use-after-free」を示す分類を加えていた。ところがJFrogが対象版をビルドし、実コードとPoCを照合すると、存在しない関数や行番号、架空の修正が次々に見つかった。JFrogとSQLite開発元はAI生成の疑いを指摘している。今回表に出たのは、もっともらしい報告を提出するコストと、人間が誤りを証明するコストの差である。
9.8を含む6件、実コード照合で崩れる
MITREは2026年7月27日、SQLiteの脆弱性とされた6件のCVEを公開した。いずれも解放済みメモリの使用（use-after-free）を主張し、サービス妨害や情報漏洩、任意コード実行につながると説明していた。CISAのAuthorized Data Publisher（ADP）は6件にCVSS v3.1の値を加え、51303を9.8、51300を9.1と評価した。複数のレコードには、攻撃コードが存在することを示す「Exploitation: poc」も付いた。
JFrogは説明文の雰囲気を判定するのではなく、SQLite 3.41.0、3.51.2、3.51.3を隔離したDocker環境でビルドし、AddressSanitizerを有効にしてPoCを走らせた。その結果、6件ともクラッシュやメモリエラーを再現しなかった。
| CVE | 主張の破綻 | 却下前のCISA ADP CVSS |
|---|---|---|
| CVE-2026-51302 | exprComputeOperands()が対象版に存在しない |
7.5 |
| CVE-2026-51303 | 修正済みとされた3.51.3でexpr.cに変更がなく、PoCは構文解析で失敗 |
9.8 |
| CVE-2026-51300 | 指定行はコメントとメモリ確保で、PoCは正常終了 | 9.1 |
| CVE-2026-51297 | jsonBlobEdit()が対象版に存在しない |
8.8 |
| CVE-2026-51296 | 2706行のファイルに対し3555行と3575行を参照 | 7.5 |
| CVE-2026-51304 | 関数の引数を誤り、実装は解放後のポインタをゼロ化 | 7.5 |
文章のAIらしさは補助的な手掛かりにすぎない。6件を崩したのは、対象版のソースと実行結果である。SQLite開発元も現在、6件を「再現不能」で「AIの幻覚とみられる」と一覧に記し、SQLiteのバグではないと明記している。
JFrogは同じGitHubアカウントにあった55件を調べ、54件を完全な捏造、残る1件を実在するバグに未検証のCVE情報を重ねたものと報告した。ただし、SQLite 6件ほど詳細に再現試験したわけではない。確実に追える中心事実は、6件がMITREによって7月31日にREJECTEDへ変更され、理由欄に「追加調査でセキュリティ問題ではないと判明した」と記録されたことだ。
CVE、CISA、NVDは別の工程
誤情報がどこを通ったのかを理解するには、三つの役割を分ける必要がある。CVE Numbering Authority（CNA）は脆弱性を判定して識別番号とレコードを公開する。CISA ADPは公開済みレコードの別コンテナへCVSS、CWE、SSVCなどを補う。NISTのNational Vulnerability Database（NVD）はCVE Listを公開から約1時間で自動取り込み、影響製品を表すCPEなどを独自に追加する。
CVEの運用規則は、割当前に脆弱性の存在を判断できる「合理的な証拠」をCNAへ求めている。同時に、誠実に確認しても判断が明確にならない場合は、識別と議論を可能にするため採番側へ倒すよう定める。すべての案件でCNA自身がPoCを再現するという一律の要件は置かれていない。公開済み案件で最適なCNAが72時間以内に割当を断るか応答しなければ、適切なRootが脆弱性の有無を判断する。
この設計は、世界中の脆弱性へ共通名を素早く与えるためのものだ。CVE Program自身も、CVE IDは共通識別子であり、対処の要否やリスクを単独で決める指示ではないと説明している。今回の問題は、基礎レコードの前提が誤っていても、後段の補完がCVSSやCWEを整え、下流からは情報量の多い記録に見える点にある。ADPはCNAが書いた領域を変更できないため、補完処理は元の主張を再現検証する代替にならない。
実際、CVE-2026-51300にはCISA ADPから9.1というスコアと「Exploitation: poc」が追加されたが、JFrogが添付クエリを実行すると正常な結果を返し、メモリエラーは起きなかった。構造化データの充実度と、脆弱性が実在する確度は別に扱う必要がある。
1四半期1万5176件という処理圧力
CVE Programが2026年第1四半期に公開したレコードは1万5176件で、前四半期の1万2796件から19%増えた。予約されたIDは2万1530件に達し、1万5479件から39%増加した。Programは予約増の一因をAIによる脆弱性発見と申請の増加だと説明している。これは偽報告の件数を示す数字ではないが、検証側が受け取る量の変化は明白だ。
公開後の補完にも処理圧力がかかっている。米商務省監察総監室によると、NVDの未処理レコードは2024年6月初めの約1万3000件から2025年末に2万7000件超へ膨らんだ。2026年の年間報告数は6万件を超えると予測されている。NVD分析者の作業では、重大度スコアとCPEによる適用範囲の付与が推定80%の時間を占める。
ただし、NVDの滞留が今回の誤採番を直接引き起こしたとする証拠はない。採番はCVE側、補完はCISAとNVD側で行われる。どの工程も全件のビルドとPoC再現を担う体制ではないため、提出量が増えるほど検証コストが供給者や外部研究者へ戻ってくる。
その負担は既に開発を圧迫している。curlは2026年7月の1か月間、脆弱性報告の受付を停止した。保守者のDaniel Stenbergは8月3日、報告対応から離れたことで、滞っていた機能や変更のレビューへ時間を戻せたと振り返った。curl以外のセキュリティチームでは、報告の洪水が減っていなかったとも記している。偽報告を1件送る費用が下がっても、誤りだと示す側は対象版を読み、ビルドし、実行しなければならない。
CVE番号より先に確認する5点
新しいCVEを見つけたとき、番号とCVSSを起点に自動起票する運用は速い。そのまま緊急パッチへ進むと、今回のようなレコードが調査時間を奪い、不要なコード変更まで誘発する。少なくとも次の5点を同じ画面で確認できる運用が要る。
- 製品の供給者や開発元が問題を認めているか。
- 修正コミットやプルリクエストがあり、主張したコードと対応しているか。
- 影響版に関数、行番号、実行経路が実在するか。
- PoCが安全な隔離環境で再現し、観測結果が説明と一致するか。
- CVSS、CWE、CPEがCNA、CISA ADP、NVDのどこから来た値か。
この確認は、CVEや自動化を捨てるためのものではない。CVE IDを相関の鍵として使い、修正の優先順位は供給者の情報と再現可能な証拠で決めるための分業である。今回の6件は既にREJECTEDであり、SQLiteの緊急更新理由として使ってはならない。次に同じ誤りを止められるかは、スキャナーが却下状態を速やかに反映し、組織がスコアだけで動く自動処理へ供給者確認と証拠の有無を組み込めるかで決まる。
