SQLiteのCritical CVE 6件は実在しなかった — LLM slopがCVEパイプラインを汚染する構造

はじめに

依存パッケージに CVSS 9.8 の Critical 脆弱性アラートが飛んできたら、あなたはどうするだろうか。おそらく最優先でチケットを切り、バージョンを上げ、リリースを前倒しする。多くの現場でその判断は正しい。

だが2026年7月末、世界で最も widely deployed なデータベースである SQLite に対して Critical / High 級の CVE が6件立て続けに登録され、そのすべてが実在しない脆弱性だった。JFrog Security Research の検証によって、これらが LLM に書かせたとおぼしき捏造報告——いわゆる LLM slop ——であることが判明し、MITRE は該当 CVE を Rejected に切り替えた。Hacker News で656ポイントを集めたこの一件は、単なる笑い話ではない。CVE という、現代のソフトウェア開発が全面的に依存している信頼インフラの検証工程が、実は驚くほど脆いという事実を突きつけている。本記事では、捏造がどう作られどう通過したのか、そしてエンジニアは明日から何を変えるべきかを整理する。

何が起きたか — 4日間で55件、うち54件が捏造

発端は、新規に作られた無名の GitHub リポジトリ（programmervuln/cveadvisory-）だ。このアカウントはわずか4日間で55件のアドバイザリを公開し、JFrog の調査によればそのうち54件が完全な捏造だったという。

うち SQLite を標的にしたものが以下の6件である。

CVE ID	主張されたスコア	主張された内容
CVE-2026-51302	9.8 Critical	`exprComputeOperands()` の use-after-free
CVE-2026-51303	9.8 Critical	`ExprListDelete()` の欠陥
CVE-2026-51300	9.1 Critical	特定行におけるメモリ破壊
CVE-2026-51297	8.8 High	`jsonBlobEdit()` の脆弱性
CVE-2026-51296	7.5 High	`json.c` 3555行・3575行の問題
CVE-2026-51304	7.5 High	`sqlite3ExprListDelete()` の欠陥

重要なのは、これらが「怪しい報告」として隅に置かれたのではなく、正規のパイプラインを通って Critical として流通したという点だ。CISA の Vulnrichment（ADP）は2026年7月30日に CVE-2026-51302 へ CVSS v3.1 スコアを付与している。Red Hat も当初は極めて高いスコアを割り当て、後に 7.6 High へ引き下げた。つまり、脆弱性スキャナやアラート基盤から見れば、この6件は数日間まったく正規の Critical CVE として振る舞っていた。

技術的な破綻 — 「存在しない関数」の脆弱性

JFrog がソースコードと突き合わせた結果は、控えめに言っても壊滅的だった。捏造の痕跡は、LLM のハルシネーション（もっともらしいが実在しない出力）の典型的なパターンを示している。

存在しない関数を指している。 CVE-2026-51302 は SQLite 3.41 における exprComputeOperands() の use-after-free を主張したが、この関数は 3.41 に存在しない。追加されたのは2025年半ばである。さらに、関連する sqlite3ReleaseTempReg() はレジスタ番号を配列に回収して再利用する設計であり、構造上 UAF が起こり得ない。CVE-2026-51297 が挙げた jsonBlobEdit() も同様で、後の JSONB 実装で導入された関数だ。CVE-2026-51304 に至っては、sqlite3ExprListDelete() の単一引数シグネチャという実在しない形を前提にしていた。

行番号がファイルの外を指している。 CVE-2026-51296 は json.c の 3555行目と 3575行目を問題箇所としたが、対象バージョン 3.41.0 の json.c は2706行しかない。CVE-2026-51300 が指した1012行・1026行は、実際にはコメント行とメモリ確保の呼び出しだった。

修正されたはずのパッチが存在しない。 CVE-2026-51303 は特定バージョンでの修正を主張したが、3.51.2 と 3.51.3 の差分を取ると src/expr.c には変更が1行もない。

そして PoC が動かない。 添付されていた再現コードはすべて、クラッシュを含むいかなる異常も引き起こさなかった。

「実在するファイル名・それらしい関数名・具体的な行番号・整った PoC 形式」——LLM が最も得意とする、形式だけが完璧な生成物である。逆に言えば、形式のチェックしかしない審査は原理的にこれを弾けない。

なぜ通過してしまうのか — 検証工程の空洞化

技術的にこれほど雑な報告が Critical として流通した理由は、CVE エコシステムの構造にある。

第一に、申請時点で本人確認も再現確認も要求されない。JFrog が指摘するとおり、MITRE の公開フォームは実質的に誰でも脆弱性の記述を投稿でき、CVSS スコアを提案できる。パイプラインのどの段階にも「PoC が実際に再現すること」を必須とする関門がない。もっともらしい文章が書ければ、そのまま通る。

第二に、深い検証を担っていた NVD が事実上撤退した。かつて NIST の NVD は流入する CVE を人手で分析・検証・エンリッチしていたが、2024年2月に深い分析を停止。CVE 提出数は2020年から2025年で263%増加し、backlog は約29,000件が「Not Scheduled」に再分類された。さらに2026年4月15日以降、NVD がエンリッチするのは CISA KEV 掲載・連邦政府ソフトウェア・大統領令14028の重要ソフトウェアに該当するものだけで、それ以外は CVSS も CPE も CWE も付かない「Lowest Priority」として素通りする。

第三に、下流の自動化が誤りを増幅する。エンリッチの空白を埋めるべく ADP やベンダーがスコアを補完するが、元の主張が捏造なら、補完されたスコアは「捏造に権威を与える」働きをしてしまう。そこから先は Dependabot や Trivy、Snyk といったスキャナが機械的に拾い、Critical として自動チケット化され、自動 PR が飛ぶ。人間が原典に当たる工程は、どこにも残っていない。

なお SQLite 開発陣は、この問題を以前から見抜いていた。公式の CVE ページには次のように明記されている。

SQLite 開発者は CVE を書かない。SQLite に関する CVE は第三者が、多くの場合コア開発者からの入力なしに作成したものである。（中略）SQLite に関する CVE が権威ある情報を含んでいると仮定すべきではない。

同ページは今回の6件を一括して「Not a bug in SQLite（再現不能な AI のハルシネーション）」と記載している。そして NVD 上でも、CVE-2026-51302 は2026年7月31日付で Rejected となった（CISA-ADP が前日に付けた CVSS スコアも同時に削除されている）。The Register の取材によれば、MITRE は当該リポジトリ由来の CVE 群をまとめて拒否した一方、GitHub Advisory Database には掲載が残っている状態も報じられており、どのデータソースを見るかで結論が変わる期間が生じていた。

エンジニアへの影響 — 何を変えるべきか

この件が実務に突きつけるのは、「Critical CVE アラートを、人間の検証なしに自動実行するワークフローは危険」というシンプルな結論だ。誤検知は開発時間を奪うだけでなく、実在する脆弱性への対応リソースを希釈する。

明日からできる対策は次の4点に集約できる。

一次情報はベンダー公式の advisory を見る。 SQLite なら sqlite.org/cves.html、多くの OSS はセキュリティページや GitHub Security Advisory を持つ。NVD のスコアは、いまや「検証済み」を意味しない。
報告者を見る。 作成直後のアカウントが短期間に大量のアドバイザリを出しているなら、それ自体が強いシグナルだ。今回は「4日で55件」だった。
主張された関数・行番号が対象バージョンに実在するか確かめる。 git log -S 関数名 や git blame で導入時期を追えば、今回のケースは数分で崩せた。存在しない関数の脆弱性は存在しない。
PoC を再現させてから優先度を決める。 再現しない報告は、少なくとも「Critical として今夜リリースを止める」根拠にはならない。

そしてもう一つ、AI エージェントに脆弱性対応を任せている場合の落とし穴がある。JFrog も指摘するとおり、捏造 CVE を入力されたエージェントは、存在しないバグに対する「修正」コードを平然と書いてしまう。AI が生成した虚偽を AI が受け取って不要な変更を積む——この閉じたループに人間の検証点を残しておくことが、いま最も費用対効果の高い防御策になる。

まとめ

SQLite の Critical / High CVE 6件が、存在しない関数・範囲外の行番号・動かない PoC に基づく捏造だったと JFrog が検証した。同一リポジトリの55件中54件が同様だった。
捏造は正規パイプラインを通過し、CISA-ADP のスコア付与を経て数日間 Critical として流通。MITRE は7月31日に Rejected とし、SQLite 公式も「AI のハルシネーション」と明記した。
背景には、申請時に再現確認を課さない CVE 申請プロセスと、2024年以降段階的に検証機能を縮小した NVD の運用変更がある。
実務では、ベンダー公式 advisory を一次情報とし、報告者・コードの実在性・PoC 再現性を確認してから優先度を決める運用への移行が必要になる。

curl プロジェクトが AI slop レポートの氾濫で2026年2月に HackerOne の受付を停止した（その後、報告品質の改善を受けて3月に復帰）ことと、今回の件は同じ根を持つ。生成コストがほぼゼロになった以上、検証されていない脆弱性情報の量は今後も増え続ける。CVE 番号が付いていることは、もはや「誰かが確認した」ことを意味しない。その前提を運用に織り込めるかどうかが、これからの脆弱性管理の分かれ目になる。

今日のその他のニュース

Don’t be a meat proxy（HN 1517pt） — AI の出力をレビューもせず次工程へ流すだけの働き方を「肉の中継役」と呼び、そこに人間の付加価値は残らないと論じる。同日3位圏の Prevent cognitive debt by manually retyping LLM-generated code（307pt）が「生成コードを手で打ち直す」という具体的な対抗策を提示しており、対の記事として読める。

Qwen3.8-Max（HN 987pt） — Alibaba の最新フラッグシップ。単発のコード生成ではなく「Coding and Cowork（協働）」を評価軸に据えた点が特徴。同日には AirLLM で 4GB GPU 単体の 70B 推論、Kimi K3 を枝刈りして Mac Studio 1台で動かす試みなども並び、巨大オープンウェイトのローカル実行が同時進行している。

ADR（Any Decision Record）という文化（はてブ 139） — ADR の A を Architecture ではなく Any と読み替え、技術選定に限らずあらゆる意思決定を記録として残す運用。AI に開発を任せる比率が上がるほど「なぜその判断をしたか」がコードから読み取れなくなるため、決定ログの価値は上がっている。