ハクソク

世界を動かす技術を、日本語で。

幻覚によるSQLiteの脆弱性に対する重要なCVEが発行されました

2026年8月3日原文(research.jfrog.com)

概要

  • GitHub上の新規リポジトリから発表されたSQLite脆弱性アドバイザリの大半が AI生成の偽情報 であると判明
  • NVDやCISAが即座に「重大」と評価したが、 実際にはコードやPoCが存在しない
  • SQLite公式アドバイザリには掲載されておらず、 調査で全て虚偽と確認
  • MITRE経由CVEsの審査体制の脆弱性が露呈
  • 組織やAIによる自動対応プロセスへの 深刻な影響と対策の必要性

GitHub発のSQLite脆弱性アドバイザリの検証結果

  • programmervuln/cveadvisory- リポジトリから50件超のSQLite CVEが公開
  • NVDやCISA が即座に重大判定、 Red Hat も一部CVEで10.0 Criticalを付与
  • JFrog のセキュリティリサーチャーが詳細検証を実施
    • 指摘されたコードが 該当バージョンに存在しない 事例多数
    • PoC（概念実証）のSQL文も クラッシュや問題を再現できず
    • SQLite公式の脆弱性ページ には一切掲載なし
  • Gptzero 等AI判定ツールで AI生成コンテンツ警告 を検出

主要CVEsの検証詳細

  • CVE-2026-51302: exprComputeOperands()のUAF主張
    • 該当関数は SQLite 3.41には未実装、ロジック上もUAF不可能
    • PoCも 正常動作 し再現せず
  • CVE-2026-51303: ExprListDelete()のback-ref未解放主張
    • 該当構造や修正コミットが存在せず、PoCはSQLパースエラー
  • CVE-2026-51300: sqlite3ExprDelete()の左辺式ポインタ未解放主張
    • 指定行番号はコメント/無関係コード、UAF発生せず
    • SQLは正常動作し メモリリークなし
  • CVE-2026-51297/51296: jsonBlobEdit()やjsonRemoveFuncでのUAF主張
    • 関数や該当行が存在せず、PoCもエラーのみ
  • CVE-2026-51304: pOrderBy->nExprのpost-free参照主張
    • 関数シグネチャや実装が異なり、SQLiteは即座にポインタnull化
    • PoCも 正常にソート結果を返却

CVE登録・審査プロセスの問題点

  • MITREの公開フォーム経由 で誰でもCVSS値付きでCVE申請可能
  • 従来は NIST/NVD が手動で精査し信頼性を担保
  • 2024年2月以降、 報告急増でNVDの審査が機能停止
    • CISAやADP による補完も追いつかず
    • 証拠や再現性のチェック工程が存在しない ため、虚偽アドバイザリが流入
  • 55件中54件が完全な捏造、1件のみ本物だがメタデータ不備

LLMスロップCVEsの特徴とリスク

  • 公式ベンダーの裏付けなし （例: sqlite.org/cves.html未掲載）
  • コミットやPRの参照無し
  • CPEやバージョン範囲が矛盾
  • 実装されていない関数や行番号の引用
  • 組織やAIエージェントが無駄な調査・パッチ適用を強いられる
  • AIによる自動トリアージ/修正で誤ったパッチ生成や無意味な作業発生

組織・開発者への推奨対策

  • 未知・未検証ソースの新規CVEは鵜呑みにしない
  • 重大判定CVEは内容とスコアの整合性を必ず確認
  • 自組織の環境が本当に影響を受けるか精査
  • PoCを安全なテスト環境で必ず再現検証
  • GHSA、Red Hat、NVD等へ正式に虚偽報告を通報済み

まとめ

  • AI生成の虚偽脆弱性アドバイザリが公式経路を通じて拡散
  • CVE登録・審査体制の見直しと、現場での検証・裏付けの徹底が不可欠
  • 自動化・AI活用時代の新たなセキュリティリスクとして要注意

Hackerたちの意見

これは、すべてのCVEをパッチすることが義務付けられている組織にとって、楽しそうだね。

└

これが最初に思ったことなんだけど、攻撃的に使われたら最悪だよね。私が考える最良の防御策は、問題を人間が見る前にエージェントが再現することだけど、それでもお金がかかるよね。

└

どんな組織がそんなポリシーを持ってるのか、すごく気になる。大きさに関わらず、かなりの自己欺瞞がないと実現不可能だと思うし（オープンソースの使用を禁止するってなると、CVE自体が意味をなさなくなるし）。

└

その組織は、新しい現実に適応しなきゃいけないね。つまり、いくつかのCVEは実際には存在しないってこと。

└

参照されてるけど存在しないファイルを作って、それから修正するってことだね /s

└

すべての組織にはポリシーの例外があるよね。これもその一つだと思う。

└

正直言って、あまり良くない。うちのセキュリティチームは完全にイライラしてるし、こんなことで時間を無駄にしてる。詐欺を見つけて、ちょっと調査して、正当な理由をつけてDNFを書いたら、向こうは記録を更新して、みんなで「誰かがスキャンを更新してくれることを願う」って感じ。何かが崩れると思うし、楽観的なオープンフィリングはキャンセルされるんじゃないかな。

└

そうでもないよ。LLMもパッチを幻覚することができるからね :-)

└

幻覚されたCVEをパッチする手順: git stash -m "はぁ" git commit --allow-empty -m "Patch: CVE-2026-51302" git stash pop

こういうことの問題は、S/N比（信号対雑音比）が下がっちゃうことなんだよね。だから、正当なCVEを見分けるのがすごく難しくなる。でも、一方で、LLMがたくさんの正当なCVEを見つけてるのは知ってるし、悪意のある人たちがそれを最大限に利用してると思うよ。

└

現在は、AIが最終的にすべてのソフトウェアを以前よりもずっと安全にする過渡期にいるみたいだね。この期間中、攻撃と防御のサイバーセキュリティのすべての部分がかなり急速に変わる。騒がしいCVEは、たぶんエージェントが人間がレビューする前に脆弱性を確認することにつながるだろう。エージェントのレビューに関して考えられる問題は、 - LLMを使ってレビューするコスト - リポジトリに簡単に組み込めるわけではない（ドメイン知識 + スタック特有の脆弱性を探す方法） - 特に人間的な観点から、防御的にモデルを使えるかどうか。これが一番興味深い。AIプロバイダーはどうやって「良い人か悪い人か」を判断するの？オープンソースが追いついてくることは重要なのかな？好き嫌いに関わらず、サイバーアームレースのような状況にいるよね。

└

大多数のCVEは実際には悪用できない、基本的にはノイズだよね。生成されるCVEの大半は、リンクされた記事のようなノイズか、悪用できない種類のノイズだと思う。

Hacker Newsで議論の続きを見る