GitHub リポジトリから公開された SQLite「LLM slop」CVE の検証結果

数日間にわたり、

programmervuln/cveadvisory-

• 内容: これらの告発書は、LLM が生成した疑似コード（「LLM slop」）であると判断されています。
• 件数: 50 件以上の CVE が発表され、そのうち 51 件のみが例外として除外されています。
• 初動対応:
  • NVD（国家脆弱性データベース） これらを速やかに「重大」レベルと格付けしました。
  • CISA（サイバー安全・安全保障庁）有権データ出版者（ADP）も同様に承認しました。

しかし、JFrog のセキュリティ研究者による詳細な検証の結果、これらの主張は完全に崩壊しました。

主要な検証結果（嘘と矛盾）

以下の事実関係が確認されました。

• コードの不存在: 言及されたコードは、該当するバージョンには存在せず、また無関係なロジックを参照していました。
• PoC の機能不全: PoC（概念実証）ペイロードのテストを行ったところ、いかなるクラッシュも誘発されませんでした。
• 公式リストからの除外: これらの CVE のいずれも、実際の脆弱性を追跡する「黄金基準」とされる SQLite 公式告発ページにはリストされていませんでした。
• AI 生成コンテンツ: Gptzero を使用して検証した結果、すべての内容が AI によって生成されたものであることが判明しました。
  • これらすべての告発書を単一のファイルに結合すると、AI 生成コンテンツ警告がトリガーされました。

事例：Red Hat のスコア変更

昨日の調査で CVE-2026-51302 に着目した際、Red Hat は当初を「Critical（重大）」としていましたが、現在では「High（高）」にダウングレードされています。

exprComputeOperands()

ExprListDelete()

sqlite3ExprDelete()

jsonBlobEdit()

jsonRemoveFunc

pOrderBy->nExpr

検証ワークフロー

これらの報告を厳格に検証するため、以下の隔離されたテストを行うワークフローを確立しました。

• ソースコードの点検:
  • 公式

    sqlite/sqlite

    リポジトリをクローン。
  • ターゲットタグ（

    version-3.41.0

    ,

    version-3.51.2

    ,

    version-3.51.3

    ）を検出。
  • 報告された脆弱性のメカニズムと実際のソースコードを比較。
• クリーン環境でのビルド:
  • 公式 SQLite リリースを、孤立した Docker コンテナの内部で直接コンパイルし、環境汚染を防ぐ。
• PoC の実行:
  • ASan（アドレス サン チェイザー）によるメモリバグ検出のためのインスツルメンテーション付きコンパイル済み SQLite バイナリに、PoC SQL ステートメントを投入。
• NVD とメタデータのオーディット:
  • NVD と GHSA フィードにおける CPE パターンと告発書メタデータを評価し、追跡精度を相互検証。

詳細なコード解析結果

1.

sqlite3ReleaseTempReg()

の分析

• 報告された脆弱性:

  • sqlite3ReleaseTempReg()

    が

    regFree1

    に懸念ポインタを残すと主張され、これが後に参照解除されることによる UAF（使用後の解放）が想定されました。
• 調査結果:
  • 主要な問題点は、報告されたバージョン（3.41）において

    exprComputeOperands()

    が実装されていないことです（2025 年半ばに追加）。

  • sqlite3ReleaseTempReg()

    のメカニズムにはヒープの解放は関与していません。単にレジスタインデックスを循環させるため、設計上 UAF は不可能です。
• コード参照:

  /* expr.c:6562, SQLite 3.41.0 */
  void sqlite3ReleaseTempReg(Parse *pParse, int iReg){
    if( iReg ){
      sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);
      if( pParse->nTempReg < ArraySize(pParse->aTempReg) ){
        pParse->aTempReg[pParse->nTempReg++] = iReg;
      }
    }
  }
  

• PoC テスト: クラッシュは発生せず、クエリが正常に実行されました。

2.

ExprListDelete()

の分析

• 報告された脆弱性:
  • 子ノードを解放する際に親構造体内のバックリファレンスをクリアせず、バージョン 3.51.3 で修正されると主張。
• 調査結果:
  • Expr、Select、Window 構造体において、そのような状態をもたらす可能性のあるバックリファレンスポインタは存在しません。
  • バージョン 3.51.2 と 3.51.3 の差分を見ると、

    src/expr.c

    に一切の変更がありません。「修正」は完全に捏造されたものです。
• PoC テスト: PoC は無効な SQL であり、パーザ段階で失敗しました。

3.

sqlite3ExprDelete()

の分析

• 報告された脆弱性:
  • UAF が発生すると主張され、expr.c の特定の行番号（1012, 1026）を指す。
• 調査結果:
  • 引用された行番号はコメントおよびメモリ割り当てコールであり、削除ロジックとは関係ありません。
  • OOM エラー処理中に呼び出されるが、スコープの終わりでの呼び出しのため、ポインタが再利用されることはありません。
• コード参照:

  /* expr.c:1330, SQLite 3.41.0 */
  void sqlite3ExprDelete(sqlite3 *db, Expr *p){
    if( p ) sqlite3ExprDeleteNN(db, p);
  }
  

• PoC テスト: 有効な SQL クエリとして正常に実行され、メモリリークやエラーは発生しませんでした。

4.

jsonBlobEdit()

の分析

• 報告された脆弱性:

  • jsonParseFree()

    が懸念リファレンスを残しておき、

    jsonBlobEdit()

    でアクセスされると主張。
• 調査結果:

  • jsonBlobEdit()

    はターゲットバージョン（3.41.0）には存在しません（後期に JSONB 実装の一部として導入）。
  • ターゲットバージョンにおいて、

    jsonParseFree()

    は厳密にデストラクタ内で使用され、周辺構造体は直ちに廃棄されます。
• PoC テスト: PoC は即座に不正な JSON エラーを起こし、脆弱性が存在するとされるロジックに到達することを阻止しました。

5.

jsonRemoveFunc

の分析

• 報告された脆弱性:
  • json.c の 3555 行と 3575 行で UAF が発生すると報告。
• 調査結果:
  • バージョン 3.41.0 では

    src/json.c

    は 2,706 行までしかありません。引用された行番号は存在しません。
  • 実際の関数実装は約 2,000 行前で見つかり、メモリ管理上の欠陥は見つかりませんでした。
• PoC テスト: ペイロードは JSON パース段階で失敗し、メモリーは未触動のままです。

6.

sqlite3ExprListDelete()

の分析

• 報告された脆弱性:

  • sqlite3ExprListDelete(pOrderBy)

    がソート順リストを解放する一方、その後のコードが

    pOrderBy->nExpr

    を読むと主張。
• 調査結果:
  • 告発書に記載されている単一引数のシグネチャは存在しません。実際のシグネチャでは

    sqlite3 *db

    が必須です。
  • SQLite は削除直後にポインタを明示的に NULL にしています：

  /* select.c:3761, SQLite 3.41.0 */
  sqlite3ExprListDelete(db, pPrior->pOrderBy);
  pPrior->pOrderBy = 0;   /* ポインタは即座にクリアされ、参照解除不可能 */
  

• PoC テスト: PoC ペイロードは正常に実行され、ソートされた結果を問題なく返しました。

CVE 提出プロセスの脆弱性

MITRE の公開フォームを通じた CVE 提出プロセスには、真正な本人確認が一切含まれていません。実質的に誰でも CVSS スコアを提案でき、過去に NIST が機能していました。しかし、2024 年 2 月にこの「安全装置」は故障しました。

• 現状の課題:
  • 大量の脆弱性報告を受け付け、NIST は深い分析を一時停止せざるを得ませんでした。
  • CISA や ADP が独自の補強活動を取り組みますが、グローバルなパイプラインは断片的になり、処理 backlog に溺れています。
  • PoC やバグ再現証明を要求しないため、偽の告発書が GHSA などの下流データベースやエンタープライズスキャナーに到達しています。

LLM slop 型 CVE を特定するための「赤信号」

AI 生成コンテンツである可能性が高い CVE の兆候を確認してください。

• ベンダーによる裏付けの欠如:
  • 公式の管理者セキュリティページ（例：

    sqlite.org/cves.html

    ）に問題言及がないこと。
• コミット履歴の不在:
  • リファレンスフィールドにコミットハッシュやプルリクエストがリンクされていないこと。
• メタデータの矛盾:
  • CPE プロダクト定義が空であること、または告発書の物語と衝突するバージョン範囲が含まれていること。
• 存在しないコード参照:
  • 主張されたターゲットバージョンには存在しない関数を引用していること。
  • EOF（ファイル終了）を越えた行番号を言及していること。

組織への影響

• リソースの浪費: 実際の脆弱性が存在しないにもかかわらず調査やパッチ適用に時間を費やす原因となります。
• データベース汚染: 脆弱性データベース自体を汚染させます。
• 自動化システムへのリスク: Critical レベルの CVE は自動優先順位付けされ、AI エージェントは存在しないコードに基づく脆弱な関数の特定を試みたり、誤ったパッチを生成したりする可能性があります。

推奨アクション：影響を受けないための対策

1. 盲目的に信頼しない: 未知かつ未検証のソースから新発売された CVE を安易に信じてはいけません。
2. スコアと実情を確認する: Critical レベルの CVE も調査し、スコアが脆弱性と一致しているか理解しましょう。
3. 影響範囲を確認する: ご自身の環境が実際にその CVE に影響を受けているかどうかを確認してください。
4. PoC を実行再現する: 可能であれば、安全な環境で提供された PoC を使用して報告された問題を実行・再現してください。

これらの発見を是正に貢献するため、GHSA、Red Hat、および NVD に対して正式に報告済みです。