広く導入されているオープンソースのアイデンティティ・アクセス管理サーバーで、Red Hatビルドの基盤ともなっているKeycloakにおいて、アクセス制御の不備に関する脆弱性が新たに公表されました。
CVE-2026-17059として追跡されているこの脆弱性は、意図的に権限を制限された管理者アカウントが、本来閲覧できないはずのユーザーの個人データを、メインのユーザーディレクトリではなくロールのメンバーシップを照会することで収集できてしまうというものです。
Keycloakの主要なユーザー一覧表示用エンドポイントであるGET/admin/realms/{realm}/usersは、可視性の制御を正しく実施しています。
query-usersとview-realmの権限のみを持つアカウントがユーザーを検索すると、アクセスモデルの想定どおり空の配列が返されます。これは、このエンドポイントがすべての結果を、呼び出し元の権限に基づいて各ユーザーをフィルタリングするヘルパーメソッド経由で処理してから返す仕組みになっているためです。
問題は、これと似た別のエンドポイントに存在します。ロールのメンバーを一覧表示するGET /admin/realms/{realm}/roles/{role-name}/usersは、呼び出し元がそのロールを閲覧でき、かつ一般的なユーザークエリを実行できるかどうかしか確認していません。
同じユーザー単位の可視性フィルターが適用されることは一切ありません。その結果、フロントドアからは何も取得できない同じ制限付きアカウントであっても、そのアカウントが閲覧可能な任意のロールに属するすべてのメンバーについて、ユーザー名、メールアドレス、姓名、有効/無効ステータス、メールアドレスの確認状態を含む完全なユーザーレコードを取得できてしまいます。
複数チームが存在するレルムでは、この脆弱性によって、限定的な権限しか持たないはずのヘルプデスクやサポート用アカウントが、他の全ユーザーの個人データを閲覧できるディレクトリと化してしまいます。
Escapeはこの問題を確認しました。実際に稼働しているKeycloak 999.0.0-SNAPSHOTビルド（コミット33695405ea）を用いて、単一の制限付きトークンからわずか2回のAPI呼び出しで一連の流れを再現しています。深刻度は中程度で、CVSS 3.1スコアは6.5（AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N）とされています。
この脆弱性の悪用には、Keycloakのデフォルトの管理者権限モデルが適用されたレルムにおいて、query-usersおよびview-realmのロールをすでに保持している管理者アカウントが必要です。
fine-grained admin permissions v2が有効化されているレルムは影響を受けません。この設定では、ロールメンバーへのクエリがデータストア層でフィルタリングされるためです。
開示までの経緯は迅速に進みました。Escapeは2026年7月18日にこの問題をKeycloakチームに報告し、同日中に受領確認を得ています。Red Hatは7月24日にCVE-2026-17059を公開し、Escapeの研究者であるEnzo Mongin氏(Orionexe)の功績を認めています。
Keycloakは7月28日に修正版をリリースし、.filter(auth.users()::canView)という1行を追加するだけでこの問題を解消しました。これは、関連するグループメンバー用エンドポイントにすでに適用されていた修正を踏襲したものです。このパッチはKeycloak 26.7.0に反映されています。
Escapeのチームによると、この脆弱性は、ユーザー情報を返すすべてのエンドポイントに対して「正規のユーザー一覧で拒否されるアイデンティティは、どこであっても拒否されるべきである」という同一の不変条件でテストを行った結果、自動的に発見されたとのことです。
セルフホスト型のKeycloakやRed Hatビルドを運用している組織は、特に完全な可視性を持たない限定的な権限の管理者アカウントが存在する場合、26.7.0へのアップグレードを優先すべきです。
fine-grained admin permissions v2を有効にすることで、今回のような類似エンドポイント間のフィルタリング漏れという種類の脆弱性に対して、さらなる防御層を追加できます。
SOC調査の死角を減らしましょう。ANY.RUNを活用して脅威をより早期に封じ込め、対応コストと業務への影響を軽減します。
翻訳元: https://cyberpress.org/keycloak-user-pii-oidc-client-metadata/
