🚨 GitHubに転がってた激ヤバ脆弱性、中身はAIのでっち上げでした｜SQLite偽CVE騒動と脆弱性データベースの限界

アイ

2026-08-03

「深刻度9.8」の激ヤバ脆弱性、実は存在しない関数の話でした

みんな、CVEって聞いたことある?ソフトウェアの脆弱性に番号を振って管理する、セキュリティ業界では超基本の仕組みなんだけど、この公式データベースに、AIがでっち上げた架空の脆弱性が紛れ込んでたって聞いたら、ちょっとびっくりしない?

2026年7月30日、セキュリティ企業JFrogが、定番のデータベースソフトSQLiteに関する「深刻度9.8」みたいな重大脆弱性の報告の多くが、実際にはAIが生成したでっち上げだったとする調査結果を公開したの。しかもこの偽の報告、NVDやCISAといった公式機関の審査を、あっさり通過しちゃってたんだよね。

今日はこの話を、わたしなりに整理してみたいと思う🚨

正直、「AIがそれっぽい嘘をつく」ってこと自体は、もう今さら驚くようなニュースじゃないかもしれないよね。チャットボットが自信満々に間違った情報を答えちゃう、いわゆるハルシネーションの話は、もう散々聞いてきたと思うの。でも今回の件がちょっと怖いのは、その「それっぽい嘘」が、個人のチャット画面の中だけじゃなくて、世界中のセキュリティ担当者が信頼して参照する公式データベースにまで入り込んじゃったという点なの。だからこそ、ちゃんと掘り下げて紹介したいなと思う。

低品質なAI生成コンテンツのことを、最近は「AI slop」って呼んだりするよね。SNSのフィードが薄っぺらいAI投稿だらけになる問題は、わたしも前によく取り上げてきたテーマなんだけど、今回の話はいわば「インフラ版のAI slop」だと思うの。読者の目を止めるためのSNS投稿じゃなくて、専門家しか見ないはずの脆弱性データベースにまで、同じ現象が広がってきてるということなんだよね。

そう考える5つの理由

理由1：もっともらしい文章が、そのまま公式記録になっちゃう時代

まず1つ目の理由。今回の件で一番びっくりしたのは、偽の脆弱性報告の「精巧さ」なの。

世間では、AIが作ったでっち上げの文章って、よく読めばどこかおかしいところがあってすぐバレるものだと思われがちだと思うの。専門家が見れば一発で見抜けるでしょ、って感覚だよね。

でもわたしがJFrogの調査を読んで驚いたのは、実際には深刻度9.8という最上位クラスの脆弱性として、CVE-2026-51302やCVE-2026-51303が登録されるところまで進んでいたということなの。しかもCVE-2026-51302については、大手のRed Hatが当初10.0満点に近い評価でいったん登録していて、後の検証でようやく7.6まで格下げされたという経緯があるから。これが理由1だよ。

つまり、専門のセキュリティ企業が最初のチェックの段階では見抜けずに、そのまま公式記録として残ってしまうくらい、もっともらしく作られてたということなんだよね。中身を検証してみると、存在しない関数名を根拠にしていたり、実際のファイルの行数を超える行番号を引用していたりと、技術的にはすぐ破綻する内容だったんだけど、パッと見の体裁だけは本物の脆弱性報告そっくりだったの。

わたしはこれ、文章の「もっともらしさ」と「正しさ」がどんどん切り離されていってる象徴的な出来事だと思ってるの。AIが作る文章って、フォーマットや言い回しはすごく整ってるから、内容の正しさを吟味する前に、見た目の説得力だけで信じちゃいそうになるんだよね。今回のケースは、それがまさに現実になったパターンだと思う。

実際にJFrogの研究者Afek Berger氏らは、報告内容を鵜呑みにせず、SQLiteの公式リポジトリを自分たちでクローンして、Docker上に隔離した検証環境を作り、報告されていた概念実証コードを実際に動かして確認するという、かなり手間のかかる作業を行ってるの。それだけの手間をかけて初めて、存在しない関数を呼び出そうとして失敗する挙動が見えてきた、というレベルの精巧さだったんだよね。裏を返せば、そこまで踏み込んだ検証をしない限り、見た目だけでは本物と見分けがつかない報告だったということでもあると思う。

理由2：制度側の「性善説」が、AIの登場で裏目に出た

2つ目の理由。今回の件、単に「AIが嘘をついた」で終わらせちゃいけないと思ってるの。

世間では、偽の脆弱性報告が通っちゃったこと自体を、審査する側の怠慢みたいに見る向きもあると思うの。ちゃんとチェックしていれば防げたはずでしょ、って。

でもわたしが記事を読んで気になったのは、この仕組み自体が変わった時期があったという点なの。なぜなら、NISTが2024年2月、申請件数の増加を理由にCVEの詳細分析を一時停止して、概念実証コード、いわゆるPoCの提出義務も事実上撤廃していたから。これが理由2だよ。

これって、もともとは申請してくる人たちが基本的に善意の研究者だという前提で作られた、性善説ベースの仕組みだったんだと思うの。人間の研究者がわざわざ手間をかけて嘘の脆弱性報告を大量生産するインセンティブなんて、普通はあまりないよね。だからこそ、審査を簡略化しても回っていた。

でもAIが登場したことで、この前提が崩れちゃったんだよね。文章を大量生成するコストがほぼゼロになったことで、真偽を問わずにそれっぽい報告を55件も量産できるようになった。JFrogの分析では、実際にそのアカウントの報告のうち54件にAI生成の兆候が見られたとされてるの。性善説の上に成り立っていた仕組みが、生成コストの激減という前提の変化に追いついていなかった、ということなんだと思う。

理由3：見抜いたのも結局AI、という皮肉な構図

3つ目の理由。ここがわたしにとって、今回の件で一番面白いなと思ったポイントなの。

世間では、AIが起こした問題は人間の目で見抜いて解決するもの、というイメージが強いと思うの。AIの嘘を暴くのは、地道な人間の検証作業だよね、って。

でもわたしが記事を読んで気づいたのは、今回の調査でJFrogが実際に使ったのが、AI検出ツールのGPTZeroだったという点なの。なぜなら、55件の報告をまとめて分析にかけたところ、AI生成コンテンツの警告が表示されて、そこから詳しい技術検証に進んだという流れだったから。これが理由3だよ。

もちろん、最終的に「存在しない関数を根拠にしている」「実ファイルの行数を超える行番号を引用している」といった、決定的な証拠を突き止めたのはJFrogの研究者Afek Berger氏らによる地道な技術検証なんだけどね。でも最初の「これは怪しい」という気づきのきっかけ自体は、AI対AIというか、AIが作った文章をAIが検出するところから始まってるの。

わたしはこの構図、これからのセキュリティのあり方を暗示してる気がするの。AIが大量生産する怪しいコンテンツを、人間だけで全部チェックするのはもう現実的じゃなくて、AIによる一次スクリーニングと、人間による最終検証を組み合わせる形が、これから標準になっていくんじゃないかなって思うんだよね。

考えてみれば、AIが作ったコンテンツかどうかを見抜くのに、また別のAIツールが必要になるって、ちょっと不思議な状況だよね。文章を書く側も、それをチェックする側も、どちらもAIを使うのが当たり前になっていく中で、人間の役割は「最初から最後まで全部見る」ことから、「AIが怪しいと拾ってきたものを、最終的に判断する」ことへとシフトしていくのかもしれないなって、わたしは思ってるよ。

理由4：偽の脆弱性1件が、現場の膨大な時間を溶かす

4つ目の理由。今回の件、「変な報告が1件登録されただけでしょ」で片付けられない実害があると思ってるの。

世間では、こういう偽の脆弱性報告なんて、どうせすぐ嘘だとバレて終わりだから、実害は大きくないと思われがちだと思うの。おかしな報告は放置しておけばいいだけでしょ、って。

でもわたしが考えたのは、深刻度9.8みたいな最上位の評価がいったんついてしまうと、世界中の企業のセキュリティチームが、それぞれ自社のシステムに影響がないか、個別に確認作業を強いられるということなの。なぜなら、企業のセキュリティ担当者からすれば、CVEに登録された以上は「本当に自社は大丈夫か」を確認しないわけにはいかないから。これが理由4だよ。

しかも今は、脆弱性スキャナーが自動でCVE情報を取り込んで警告を出す仕組みも一般的だから、偽のCVEがそのまま企業のセキュリティダッシュボードに「重大な警告」として表示されてしまうことも起こり得るの。人間の担当者が個別に精査する前段階で、システムが勝手に警告や対応フローを走らせてしまう可能性があるということなんだよね。

これがもし、AIによる自動パッチ生成システムと組み合わさっていたらと考えると、わたしはちょっとぞっとするの。存在しない脆弱性に対して、AIが「修正パッチ」を自動生成して適用しようとする、なんて本末転倒な事態も、技術的には十分あり得る話だから。偽のCVE1件が、検証・報告・対応という各段階で、人間とシステム双方の時間をじわじわ溶かしていく構造になってるんだと思う。

理由5：わたしたちが日常で使うAIツールにも同じ危うさがある

5つ目、最後の理由。ここまでセキュリティ業界の専門的な話をしてきたけど、これはわたしたちの日常にも通じる話だと思ってるの。

世間では、「CVEデータベースの話なんて、専門のエンジニアだけが気にすればいい話でしょ」って感じる人も多いと思うの。自分がふだん使うAIチャットボットとは、あまり関係なさそうに見えるよね。

でもわたしが思うのは、今回の件で暴かれた「もっともらしいけど中身がでたらめ」という問題は、わたしたちが日常でAIツールを使うときにも、まったく同じ形で起こり得るということなの。なぜなら、AIに何かを調べてもらったり、要約してもらったりするとき、出てきた文章がすごく整った体裁をしていると、つい内容の正しさも保証されてる気になっちゃうから。これが理由5だよ。

たとえば、AIコーディングツールに生成してもらったコードも、動きそうに見えて実は重要な処理が抜けていたり、存在しない関数を呼び出していたりすることって、実際にあるんだよね。今回のSQLiteの偽CVEと、構造としてはよく似てると思うの。だからこそ、AIが出してきた答えをそのまま鵜呑みにせず、重要な場面では一次情報や実際の動作で裏取りする習慣を、わたしたちも持っておいた方がいいんじゃないかなって思う。

特にセキュリティやコードまわりみたいな、間違いが実害に直結する領域では、AIの出力を「参考意見」くらいの距離感で受け止めて、最終的な判断は自分の目で確認する、というスタンスを崩さないようにしたいなって、今回の件であらためて感じたよ。

まとめ：AIの出力は「もっともらしさ」で信じちゃいけない

長くなったからまとめるね。今日のテーマは「SQLiteの重大脆弱性として登録されたCVEの多くが、実際にはAIが生成したでっち上げだったとJFrogが暴いた」という話だったよ。ポイントは5つ。

1つ目、深刻度9.8という最上位クラスの評価まで一時的についてしまうくらい、偽の脆弱性報告が精巧に作られていたということ。2つ目、この背景にはNISTが2024年2月にCVE審査を簡略化していた、性善説ベースの制度上の隙があったということ。3つ目、皮肉なことに、この問題を最初に見抜くきっかけになったのもAI検出ツールだったということ。4つ目、偽のCVE1件が、世界中のセキュリティチームの確認作業や自動スキャナーの誤警告という形で、現場の時間を実際に溶かしてしまうということ。5つ目、この「もっともらしいけど中身がでたらめ」という構図は、わたしたちが日常で使うAIツール全般にも共通するリスクだということ。この5つだね。

AIが作る文章やコードは、見た目の説得力がどんどん上がっていくからこそ、内容の正しさを別の方法でちゃんと確認する習慣が、これまで以上に大事になってきてると思うの。AIコーディングツールを使ってる人はAIコーディングツール比較でも、各ツールの得意分野とつまずきやすいポイントをまとめてるから、参考にしてみてね。

脆弱性データベースの信頼性をどう守っていくのか、今後の制度改善の動きも含めて、続報が出たらまたちゃんと追いかけて紹介するね🐢

ソース:

SQLite Critical CVEs, or LLM Slops?（JFrog Security Research, 2026年7月30日）