致命的なCVEか、LLMスロップか — SQLiteの事例が露呈した脆弱性報告の信頼危機
致命的なCVEか、LLMスロップか — SQLiteの事例が露呈した脆弱性報告の信頼危機
CVSS 9.8が付された六件のSQLite脆弱性報告。これは世界で最も広く配布されたオープンソースを狙った致命的な攻撃面なのか、それともLLMがもっともらしく捏造したスロップ(slop)なのか。JFrogが一つずつ再現を試みたとき露わになったのは、コードの欠陥ではなく、脆弱性報告システムそのものの欠陥であった。
導入
2026年7月30日、ソフトウェアサプライチェーンセキュリティ企業JFrogの研究者アフェク・バーガー(Afek Berger)が一編のリサーチを公開した。対象はSQLiteである。SQLiteは、あらゆる主要ブラウザ、ほぼすべてのスマートフォン、数多くの組み込み機器の中で静かに動く、地球上で最も多く配布されたソフトウェアの一つだ。そのSQLiteに数日のうちに六件のCVEが登録され、うち二件はCVSS 9.8 — 事実上満点に近い「致命的(Critical)」等級であった。常識的に言えば、世界中のセキュリティチームが直ちにパッチ適用に動くべき事件である。
ところがJFrogが六件を一つずつ手で再現してみると、再現できるものが一つもなかった。引用された関数が該当バージョンに存在せず、脆弱だとされたコード行番号がファイルの長さを超え、概念実証(PoC)ペイロードはいかなるクラッシュも引き起こさなかった。JFrogの結論は重い。これらはSQLiteのバグではなく、大量生成ツールが作り出したもっともらしい虚構 — いわゆるLLMスロップである可能性が高い、というものだ。本稿では、何が事実として確認され、それがオープンソースセキュリティ生態系のどのような構造的弱点を露わにするのかを、分けて見ていく。
再現されない「致命的」脆弱性たち
まず事実関係である。JFrogが分析したCVEは六件だ。CVE-2026-51302(CVSS 9.8 Critical)、CVE-2026-51303(9.8 Critical)、CVE-2026-51300(9.1 Critical)、CVE-2026-51297(8.8 High)、CVE-2026-51296(7.5 High)、CVE-2026-51304(7.5 High)。点数だけを見れば、どれ一つ軽く扱えないリストである。
JFrogが報告した個別の検証結果は具体的で、それゆえ反論しにくい。CVE-2026-51302はexprComputeOperands()という関数の脆弱性を主張したが、JFrogによればこの関数は2025年半ばになって追加されたもので、報告書が指し示した3.41.0バージョンにはそもそも存在しない。タイムトラベルでもしない限りあり得ない脆弱性というわけだ。CVE-2026-51303は特定リリース間のコード変更を根拠に挙げたが、JFrogが3.51.2と3.51.3の間のdiffを取ると、問題のsrc/expr.cには「変更が一切ない(absolutely no changes)」と報告された。CVE-2026-51296は脆弱な箇所として3555行目、3575行目を指したが、当のファイルは2706行しかなかった。存在しない行に存在しないバグがあったのである。CVE-2026-51304は引用した関数シグネチャそのものが実際と異なっていた。
共通点も明白だった。JFrogは六件のいずれもSQLiteの公式脆弱性告知ページに掲載されていなかったと明かした。SQLiteは相対的に脆弱性公開が透明で保守規律が厳格なプロジェクトであり、実際のセキュリティ問題であれば上流(upstream)に痕跡が残る。そうした痕跡が皆無だった。加えてJFrogがAI生成物検出ツールに報告書の文章を入れると、当該文書が「AIが生成したコンテンツ」に分類されたという。興味深いことに六件が完全に放置されたわけではなく、Red HatはCVE-2026-51302を9.8 Criticalから7.6 Highへ独自に引き下げていた。同一の脆弱性一件をめぐって採点者ごとに2点以上開くという事実は、後述するCVSS信頼問題の予告編でもある。
追跡を続けると発生源が明らかになった。JFrogによればこれらのCVEはprogrammervuln/cveadvisory-という新規作成されたGitHubリポジトリから流れ出ており、そのリポジトリには類似形態の疑わしいCVEが50件超収められていた。JFrogが同一出所のアドバイザリ55件を精査した結果、54件が「完全に捏造された(completely fabricated)」と判断され、残る一件のみが合法的だが未検証の情報を含んでいた。要するに、一箇所から噴き出した脆弱性報告の98%以上に実体がなかったという話である。
よりによって対象がSQLiteであった点が、この事件の重みを増す。もしこの六件が濾過されずに自動化スキャナーのデータベースに定着していたら、SQLiteに依存する無数の製品の依存関係リストで「致命的脆弱性発見」の警報が一斉に鳴っていたはずだ。実体のない脆弱性であっても、いったんリストに載れば、それが偽であることを証明する負担は報告者ではなく世界中の利用者と保守者へ転嫁される。一つの捏造リポジトリが生み出しうる波及の規模が、まさにこの標的選択に表れている。
CVEはなぜこれほど容易に汚染されるのか
ここからは分析である。個別の報告書がでたらめだという事実よりも重要な問いは、なぜこのようなでたらめが「CVE」という公式識別子を付け、CVSS 9.8まで得て流通しえたのか、である。答えは脆弱性識別体系の構造にある。
CVE番号はMITREが統括し、実際の採番は世界に散らばるCNA(CVE Numbering Authority)が分担する。番号は通常「予約(reservation)」方式で、脆弱性が完全に検証される前にも先に確保される。つまり識別子発行の段階には「このバグを再現して見せたか」という敷居が事実上ない。再現可能なPoC提出を強制する手続きがパイプラインに組み込まれていないのである。ここに、詳細分析と点数を付けて正本にしてくれていた米国NVD(National Vulnerability Database)が決定的なタイミングで止まった。JFrogが指摘するように、NISTは2024年2月以降、深い分析を「事実上一時停止(hit pause)」しており、その結果、検証されていないCVEが再現証明の要求なしに循環しうる断片化したシステムが残された。門番が席を外した扉から、大量生成された報告が押し寄せてきたのだ。
長らくこの脆弱な発行構造を背後で支えてきたのがNVDの深層分析であった。番号が先に出たとしても、最終的にNVDが再検討して等級を付け、影響範囲を整理してくれたからこそ、生態系はその結果を正本として信頼できた。その最終審判者が2024年以降事実上手を離したことで、発行段階の緩さを事後に濾過してくれていたセーフティネットが消えた。今のCVEリストは、敷居も低く事後監査も浅い、両方が同時に開いた状態にある。
CVSSスコアの信頼度はこの構造で特に脆弱だ。CVSSはベクトルを埋めれば機械的にスコアが出る計算式だが、そのベクトルをどう埋めるかは報告者の主張に大きく依存する。根拠が虚構なら9.8であれ7.5であれ数字に何の意味もない。先に見たRed Hatの7.6への引き下げは採点の主観性を示し、元報告の9.8はそもそも存在しないコードに付された値である。スコアが高いほど自動化された優先度キューで上位に上がり、上がるほど多くの人の時間を焼く。スロップにとってはCVSSが高いほど有利というわけだ。
非対称性がこの問題の核心である。HNの議論では、いわゆるブランドリーニ(Brandolini)の法則 — でたらめを作る費用がそれを反駁する費用よりはるかに安いという原理 — が幾度も言及された。LLMはその非対称性を産業規模に拡大する。もっともらしい脆弱性記述を50件作るには数分で足りるが、JFrogのように一つ一つソースを取ってdiffを取り、行番号を数えて反証するには熟練した研究者の一日を要する。HNの議論ではまた、LLMは結局のところ確率的テキスト予測器であり、自身がどれほど確信しているかとは無関係にもっともらしい出力を返し、コードのコメントを実際の脆弱性と取り違えるといった誤りを犯す、という指摘が出た。ゆえに「LLMが事実として提示するすべてを人間が検証しなければならない — すべてを」という強硬な主張がスレッド上位を占めていた、というのが議論の空気であった。むろん反論もあった。HNの議論では「ただのトークン予測器にすぎない」という貶めがLLMの実際の成果を見落としているという反駁、そしてソフトウェアエンジニアリングにも他の工学分野の技術士(PE)免許のような責任体系が必要だという提案も併せて交わされた。要するに論争の軸は「道具が悪いのか」ではなく「検証なき使用が悪いのか」へと移っていた。
自動化されたセキュリティリサーチのトレードオフ
この事件が実務者へ投げかける含意は三筋に分かれる。楽観シナリオは、今回のように信頼されるベンダーがスロップを早期に摘発して公開すれば、市場が自浄能力を持ち発生源リポジトリが遮断され、むしろCVE発行パイプラインに再現証明という敷居を設ける改革へつながる、という絵図だ。悲観シナリオはその逆である。JFrogが明示的に警戒した箇所がここだ — 「AIを用いて脆弱性のトリアージ(triage)と対応を自動化する環境では、この問題は一層懸念すべきものになる」。捏造されたCVEを人間ではなく自動化パイプラインが消費すれば、存在しない脆弱性に対応するために存在しない関数を「パッチ」する無意味な作業が自動生成され、その結果が再び学習データへ流れ込む汚染ループが作られる。スロップがスロップを食って育つ構造だ。
現実シナリオはその間のどこかにある。CVEインフレーションはすでに進行中であり、NVDのボトルネックは短期間で解消しにくい。ならば防衛線は個々の組織の運用規律へと降りてくる。実務的な含意は明白だ。第一に、CVSSスコア一つで自動対応をトリガーしないこと。スコアは優先度の入力であって真偽の証拠ではない。第二に、対応の前に出所(provenance)を確認すること — 上流プロジェクトの公式告知に対応する痕跡があるか、報告リポジトリは信頼に足るか、再現可能なPoCが添えられているか。SQLiteの事例でこの三つの問いのうち一つでも投げていれば、六件は最初の関門で弾かれていただろう。第三に、自動化の最終段階には人間の検証を残すこと。とりわけ「パッチを自動生成」するパイプラインほど、存在しない脆弱性に存在しない修正を適用する事故を防ぐ最小限の安全装置が要る。
保守者のバーンアウトも静かに進行する費用である。オープンソースプロジェクトのメンテナは概して少人数であり、誤った脆弱性報告一つにも評判防衛と利用者問い合わせ対応を背負う。curlのようなプロジェクトの保守者たちがAIで大量生成された低品質報告に悩まされてきたことは、この界隈ではすでに共有された疲労である。報告費用が0に収束する時代に、その費用をすべて背負うのは、いつも検証する側なのだ。
結論
リードの問いに戻ろう。六件のSQLite CVEは致命的な脆弱性か、LLMスロップか。JFrogの検証を信頼するなら答えは明らかに後者だ — 存在しない関数、ファイルの長さを超える行番号、再現されないPoCは、コードの問題ではなく報告の問題である。しかしこの事件の真の教訓は個別報告の真偽ではない。CVSS 9.8を付けてなお何の再現の敷居も通過しないまま公式識別子として流通しえたという事実、まさにその構造こそが問題なのだ。
脆弱性データベースの価値は信頼にある。「この番号が付いたから本物だ」という前提が崩れれば、残るのはノイズだけのリストと、それを一つずつ手で選り分けねばならない研究者たちの消耗である。再現優先(reproduction-first)、出所検証、そして自動化の果てに残しておいた人間の目 — 信頼を立て直す材料は華やかではない。問いを読者に手渡そう。あなたの組織は次にCVSS 9.8のCVEに出くわしたとき、まずパッチを走らせるのか、それともまずその脆弱性が本当に存在するのかを問うのか。
出典: