SQLiteの虚偽の脆弱性に関する重大なCVEが発行される

SQLiteの重大なCVE、あるいはLLMの失言か？ Afek Berger, JFrog Security Researcher | 2026年7月30日 ここ数日、新しく作成されたGitHubリポジトリ（programmervuln/cveadvisory-）が、SQLiteの脆弱性アドバイザリのバッチ（他の50以上のCVEの一部であり、1つを除いてすべてLLMの失言だと我々は考えている）を公開しました。NVDは迅速にこれらを重大とフラグ付けし、CISAのADPも同意しました。しかし、JFrogのセキュリティ研究者が検証のために掘り下げたところ、主張は崩壊しました。引用されたコードはそれらのバージョンには存在しなかったか、無関係なロジックを参照していました。PoCペイロードをテストしても、クラッシュを引き起こすことなく機能しませんでした。これらのCVEは、SQLiteの公式アドバイザリページ（実際の脆弱性を追跡するためのゴールドスタンダード）には記載されていません。このリポジトリのすべてのアドバイザリは、GptzeroでテストするとAI生成コンテンツ警告をトリガーするようです。 すべてのアドバイザリを1つのファイルにまとめることで、AI生成コンテンツの警告がトリガーされます。 これにより、これらのCVEの信頼性について疑問を抱くようになり、これらのCVEがLLMの失言である可能性を理解しました。昨日、CVE-2026-51302の1つを調査している間に、Red Hatが当初10.0の重大な深刻度スコアを割り当てていたことに気づきました。今日、CVEを再度見ると、スコアが7.6のHighにダウングレードされていることに気づきました。 分析マトリックス CVE | 報告された欠陥 | CVSS | NVDメタデータ | 監査結果 CVE-2026-51302 | exprComputeOperands()でのUAF | 9.8 CRITICAL | ピン留めされたCPE: 3.41.0 | アドバイザリは存在しない関数を言及しています。 CVE-2026-51303 | ExprListDelete()でのUAF、バック参照 | 9.8 CRITICAL | 矛盾したメタデータ | アドバイザリは存在しない修正を言及していました。 CVE-2026-51300 | sqlite3ExprDelete()でのUAF | 9.1 CRITICAL | n/aプレースホルダー | アドバイザリは脆弱性とは無関係な行を引用していました。 CVE-2026-51297 | jsonBlobEdit()経由のUAF | 8.8 HIGH | ピン留めされたCPE: 3.41.0 | アドバイザリは存在しない関数を言及しています。 CVE-2026-51296 | jsonRemoveFuncでのUAF | 7.5 HIGH | ポピュレートされたCPE: 3.41.0 | アドバイザリは存在しない行を引用していました。 CVE-2026-51304 | pOrderBy->nExprの後でのUAF | 7.5 HIGH | ベンダー/製品: n/a | アドバイザリは間違った引数数の実際の関数を示していました。 調査方法 これらのレポートを徹底的に検証するために、独立したテストワークフローを確立しました。 ソースコード検査: 公式のsqlite/sqliteリポジトリをクローンし、ターゲットタグ（version-3.41.0、version-3.51.2、version-3.51.3）をチェックアウトしました。報告された脆弱性のメカニズムと実際のソースコードを比較しました。 クリーン環境ビルド: 独立したDockerコンテナ内で公式SQLiteリリースを直接コンパイルし、環境汚染を防ぎました。 PoC実行: 各アドバイザリのPoC SQLステートメントを、AddressSanitizer（ASan）インストルメンテーション下でコンパイルされたSQLiteバイナリにそのまま入力し、メモリバグを検出しました。 NVDおよびメタデータ監査: NVDおよびGHSAフィード全体でCPEパターンとアドバイザリメタデータを評価し、追跡精度をクロスチェックしました。 詳細な技術的内訳 1. CVE-2026-51302: 存在しないロジック（9.8 Critical） 報告された脆弱性: アドバイザリは、sqlite3ReleaseTempReg()がdanglingポインタをregFree1に残し、それが後でexprComputeOperands()によって逆参照されることで、ヒープのuse-after-freeが発生すると主張しています。 発見: ここでの主な問題は、exprComputeOperands()がSQLite 3.41には存在しなかったことです。これは2025年半ばに追加されました（コミットe24f20a、280559b）。さらに、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. CVE-2026-51303: ゴースト修正（9.8 Critical） 報告された脆弱性: ExprListDelete()が子ノードを解放する際に親構造体のバック参照をクリアせず、バージョン3.51.3でパッチが適用されたと主張しています。 発見: Expr、Select、またはWindow構造体には、そのような状態につながる可能性のあるバック参照ポインタの証拠はありません。最も決定的なのは、3.51.2と3.51.3の間のdiffでsrc/expr.cに変更が全くないことです。「パッチ」は完全に偽造でした。 PoCテスト: PoCは無効なSQLであり、パーサーの段階で失敗するため、実行ロジックに実際には到達しません。 3. CVE-2026-51300: 誤った呼び出しサイト（9.1 Critical） 報告された脆弱性: 左側式のポインタがクリアされず、expr.cの特定の行番号を参照して、sqlite3ExprDelete()でUAFが発生すると主張しています。 発見: 引用された行番号（1012と1026）はコメントとメモリ割り当て呼び出しであり、どちらもpLeftや削除ロジックとは無関係です。この関数はOOMエラー処理中に呼び出されますが、ポインタが再利用されないスコープの終わりに発生するため、潜在的なUAFを防ぎます。 /* expr.c:1330, SQLite 3.41.0 */ void sqlite3ExprDelete(sqlite3 *db, Expr *p){ if( p ) sqlite3ExprDeleteNN(db, p); } PoCテスト: 有効なSQLクエリとして正常に実行され、メモリリークやエラーゼロで期待される出力を返しました。 4. CVE-2026-51297 (8.8 High) 報告された脆弱性: jsonParseFree()がdangling参照を残し、それが後でjsonBlobEdit()によってアクセスされると主張しています。 発見: 最初のケースと同様に、jsonBlobEdit()は報告されたターゲットバージョン（3.41.0）には存在しませんでした。これはJSONB実装の一部として後で導入されただけです。ターゲットバージョンでは、jsonParseFree()は、周囲の構造体が直ちに破棄されるデストラクタでのみ厳密に使用されます。 PoCテスト: PoCはすぐに不正なJSONエラーにヒットするため、コードは脆弱性が存在するとされるJSON操作ロジックに到達しません。 5. CVE-2026-51296: 不可能な行番号（7.5 High） 報告された脆弱性: json.cの3555行目と3575行目でjsonRemoveFuncのUAFを報告しています。 発見: バージョン3.41.0では、src/json.cはわずか2706行しかありません。引用された行番号は存在しません。関数の実際の実際の実装は約2000行前に見つかり、そのコードの監査ではメモリ管理の欠陥は見つかりませんでした。 PoCテスト: ペイロードはJSON解析中に失敗し、メモリは変更されません。 6. CVE-2026-51304 CVSS 7.5 (HIGH) 報告された脆弱性: sqlite3ExprListDelete(pOrderBy)が順序リストを解放し、後続のコードがpOrderBy->nExprを読み取ると主張しています。 発見: アドバイザリで報告された単一引数シグネチャは存在しません。実際のシグネチャはデータベースコンテキスト（sqlite3 *db）へのポインタを必要とします。さらに、SQLiteは削除直後にポインタを明示的にnullにします。 /* select.c:3761, SQLite 3.41.0 */ sqlite3ExprListDelete(db, pPrior->pOrderBy); pPrior->pOrderBy = 0; /* ポインタは直ちにクリアされ、逆参照は不可能 */ PoCテスト: 20列のORDER BYクエリに対して実行されたPoCペイロードは、問題なくソートされた結果を返しました。 AIの失言CVEはどのように発生するか MITREの公開フォームを介したCVE提出プロセスには、実際の身元確認が欠けており、事実上誰でも脆弱性の説明を提出し、CVSSスコアを提案できます。歴史的に、NISTは、NVD（National Vulnerability Database）の専門家が承認のスタンプを与える前に、受信したCVEを分析、検証、強化する信頼できるセーフティネットとして機能していました。しかし、そのセーフティネットは2024年2月に壊れました。大量の脆弱性レポートの急増により、NISTは深い分析を事実上一時停止しました。CISAやその他の認定データ発行者（ADP）は、独自の強化努力で介入しようとしましたが、グローバルパイプラインは現在断片化され、大量のバックログに溺れています。今日のシステムでは、プルーフオブコンセプトやバグ再現を必要とするステップがないため、もっともらしい偽のアドバイザリがパイプラインをすり抜け、GHSA、下流データベース、エンタープライズスキャナーに到達する可能性があります。 主なテイクアウト このインシデントは、自動化されたv