CVE-2026-42811 in Polaris
要約
〜によって VulDB • 2026年05月10日
平易な表現で説明すると、Apache Polaris は本来、1つのテーブルのファイルに対してのみ有効な短期間の GCS 認証情報を発行すべきですが、悪意のある名前空間またはテーブル名を使用すると、その認証情報が設定されたバケット全体で有効になってしまうことがあります。
Apache Polaris は、CEL（Common Expression Language）条件を含む Credential Access Boundary (CAB) を作成することで、Google Cloud Storage のダウンスコープ認証情報を構築します。この条件は、要求されたテーブルのストレージパスへのアクセスを制限することを意図しています。
関連する CEL 文字列は、バケット名とテーブルパスから構築されます。このテーブルパスは、名前空間とテーブルの識別子から派生します。現在のコードでは、このパスがエスケープ処理なしで CEL 式に挿入されているようです。
その結果、シングルクォートや他の URI セーフな CEL フラグメントを含む名前空間またはテーブル識別子を使用すると、意図された引用符付き文字列から抜け出し、CEL 条件の意味を変更することができます。
実際の Google Cloud Storage 上で Polaris 1.4.0 に対してプライベートテストを行ったところ、Polaris が悪意のある識別子を受け入れ、CEL パス制限が実質的に崩壊した委任された GCS 認証情報を返すことが確認されました。
これらの委任された認証情報を使用して、以下の操作が可能でした：
- 別のテーブルのオブジェクトプレフィックスの一覧表示 - 別のテーブルのメタデータ制御ファイル（Iceberg メタデータ JSON）の読み取り - 別のテーブルのオブジェクトプレフィックス配下でのオブジェクトの作成および削除 - さらに、同じバケット内の任意のテーブルパスに関連しない外部プレフィックス配下でのオブジェクトの一覧表示、読み取り、作成、および削除
最後の点が重要です。この問題は「別のテーブル」に限定されません。確認されたセットアップでは、Apache Polaris が悪意のあるテーブルの認証情報を返した後、設定されたバケット内のパス制限は実質的に消失していました。
実用的な影響として、1つの悪意のあるテーブル用の一時的な認証情報は、Polaris が認可を要求されたテーブルよりも広範になり、設定されたバケット内では実質的にバケット全体に及ぶ可能性があります。
現在の GCS テストでは、セットアップ用に広範なカタログ権限を持つ Polaris プリンシパルを使用しました。最小権限の Polaris RBAC バリアントは GCS 上でまだテストされていません。ただし、ストレージ認証情報の権限昇格動作自体は GCS 上で確認されています。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.