CVE-2026-48702 in Rekor
要約
〜によって VulDB • 2026年08月13日
Rekorは、ソフトウェアサプライチェーンの透明性ログです。バージョン0.3.0以降でバージョン1.5.2より前の期間において、`pkg/types/alpine/apk.go`内の`Package.Unmarshal()`関数は、APKファイルの署名および制御gzipメンバをメモリ内バッファに展開する際、展開後の総サイズに上限を設定していません。既存の`max_apk_metadata_size`チェック（デフォルト1MB）は、展開完了後に個々のtarエントリヘッダサイズに対してのみ適用されるため、デコンプレッションボムによる無制限なヒープメモリ消費を防ぐことはできません。攻撃者は約1000:1の圧縮率を持つgzipストリーム（例：2MBの圧縮ゼロデータ → 2GBの展開後データ）を作成できます。これをAlpine `ProposedEntry`内の`spec.package.content`として送信すると、サーバーはリクエスト処理中にフルペイロードをメモリに展開し、サーバー側のrecover()ミドルウェアでは捕捉できない致命的なGoランタイムのアウト・オブ・メモリエラーまたはOSによるOOM-killを引き起こします。この脆弱性は認証不要のエンドポイント2つから到達可能です：`POST /api/v1/log/entries (createLogEntry)`および`POST /api/v1/log/entries/retrieve (searchLogQuery)`です。これらはどちらも`V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`を呼び出し、無制限な展開処理を実行します。バージョン1.5.2でこの問題は修正されています。効果的な回避策はありません。`max_request_body_size`を設定すると暴露は軽減されますが、約1000:1の圧縮比により完全に排除されるわけではありません（1MBのボディ上限でもヒープに約1GB割り当て可能です）。また、`max_apk_metadata_size`の設定はこの脆弱性に対して効果を持ちません。これはチェックが展開後に適用されるためです。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.