GitHub やDependabotから、Keycloakの脆弱性 の通知が急に届いた会社があるかもしれません。きっかけは、10月29日にGitHubの脆弱性のデータベース へ、Keycloakの勧告5件が登録されたことです。ただし、5件とも新しい穴ではなく、修正は4か月前の6月26日に出たKeycloak 26.6.4に入っています。
Keycloak 26.6.4の告知。6月26日の時点で8件を修正していた 出典: Keycloak「Keycloak 26.6.4 released」 (引用) 26.6.4以降（26.7系や、10月13日に出た最新の26.8.1を含む）なら、サーバー の側に残る作業はありません。確かめたいのは、6月から版を上げていないサーバーと、アプリに組み込んだ「ポリシー エンフォーサー」の2つです。
6月に直り、10月にデータベースへ
時期を並べると、今回の通知の意味が分かります。
日付
出来事
2026年6月25日
Red HatがRed Hat build of Keycloakの26.4.13と26.6.4で修正。GitHubのデータベースには、修正版の記載のない重複の勧告が載る
2026年6月26日
コミュニティ版のKeycloak 26.6.4が公開。修正した脆弱性は8件
2026年6月27日
Keycloakが自身のリポジトリーで勧告を公開（GHSA-f5p5-6xmx-p252など）
2026年10月29日
GitHubのデータベースが、修正版つきの5件を登録し、重複の勧告を取り下げ
GitHubの説明では、Dependabotはデータベースに新しい脆弱性が加わったときに通知を出します。だから編集部は、今回の通知の多くが10月29日の登録によるものとみています。通知を見たら、まず部品の版を見ましょう。26.6.4以降（ポリシーエンフォーサーは26.0.10以降）なら、その通知は閉じてかまいません。
5件の中身と、攻撃に要る立場
10月29日に登録された5件は次のとおりです。
CVE
中身
深刻度（CVSS 3.1）
攻撃に要る立場
CVE-2026-9800
ポリシーエンフォーサーが、アクセス拒否のページのパスを含むURLを取り違え、役割・スコープ・UMAの許可の確認をすべて通してしまう
High（8.1）
ログインできる利用者なら誰でも
CVE-2026-9086
リダイレクトURIの検証で、大文字と小文字を混ぜた「javascript:」「data:」を見逃し、Keycloakの画面でスクリプトが動く
High（7.3）
クライアントを管理する権限か、クライアント登録の入口に届くこと
CVE-2026-9705
以前に発行された登録用のトークンで、管理者が止めたクライアントを動かし直し、シークレットを作り直せる
Medium（6.5）
古い登録用のトークンを持つ者
CVE-2026-9083
鍵の置き場所の設定に任意のパスを入れ、サーバーにどのファイルがあるかを探れる
Medium（4.9）
レルムを管理する権限
CVE-2026-9799
UMAの許可のチケットを1つ持つ利用者が、同じ種類の資源すべてに触れる
Medium（4.6）
ログインできる利用者（PERMISSIVEの設定など条件つき）
CVE-2026-9800の勧告。リポジトリーでの公開は6月27日 出典: Keycloak（GitHub）「GHSA-f5p5-6xmx-p252」 (引用) いちばん重いCVE-2026-9800は、Keycloakのサーバーではなく、アプリの側に組み込む部品の脆弱性です。ポリシーエンフォーサーはJavaのアプリが使う部品で、Keycloakで決めた許可の規則に沿って画面やAPIを守ります。修正版は26.0.10で、サーバーとは番号の付け方が違います。
ここが見落としやすい所だと、編集部は考えます。サーバーを26.8に上げても、アプリが古いポリシーエンフォーサーを抱えたままなら、ログインできる人なら誰でも規則をすり抜けられるからです。サーバーの担当とアプリの担当が違う会社ほど、どちらも「上げた」と思い込みやすいでしょう。
26.6.4より前のサーバーは、ほかの3件も残る
26.6.4で直ったのは8件で、今回の5件のほかに3件あります。この3件は、6月から7月にかけてGitHubのデータベースへ載っていました。
CVE
中身
深刻度（CVSS 3.1）
CVE-2026-11800
JWT Authorization Grantで署名の確認をすり抜け、つないだIdPの利用者になりすませる。正しいクライアントの資格情報が要る
High（8.1）
CVE-2026-9099
グループの管理者がレルムの管理者になれる
High（7.7）
CVE-2026-9795
スコープの割り当ての確認の不備による権限の昇格
High（7.3）
つまり、26.6.4より前のサーバーには、今回の通知に出てこない認証のすり抜けも残っています。通知の5件だけを見て「管理者の権限が要るものが多いから後回し」と決めると、ここを取りこぼします。
Red Hat build of Keycloakを使う会社は、Red Hatの版で見ます。Red Hatのデータでは、26.4系は26.4.13、26.6系は26.6.4で、どちらも6月25日に直りました。古いRed Hat Single Sign-On 7は、CVE-2026-9800の修正の対象外（Out of support scope）です。
リダイレクトURIの検証は、今年3回目
CVE-2026-9086はリダイレクトURIの検証のすり抜けで、GitHubのデータベースで同じ種類の勧告を探すと、今年だけで3回目になります。
公開
CVE
中身
修正版
2026年4月
CVE-2026-3872
「..;/」を使ったパスのすり抜けで、ワイルドカードの許可を越える
26.5.7
2026年5月
CVE-2026-7504
URLの利用者情報の部分（@）の解釈の違いで、ワイルドカードの許可を越える
26.6.2
2026年6月
CVE-2026-9086
大文字と小文字を混ぜた「javascript:」「data:」を見逃す
26.6.4
4月と5月の2件は、「有効なリダイレクトURI」にワイルドカード（*）を使う設定が条件でした。一方、今回の1件は、登録するURIそのものに危ない書き方を入れる手口です。検証の仕組みは毎回直されていますが、すり抜け方は毎回違います。だから編集部は、検証に頼るより、登録できるURIを絞る設定のほうが確実だとみています。ワイルドカードを使わずにURIを1つずつ書き、クライアントを登録できる人と入口を限っておけば、次の修正を待つ間も被害を受けにくくなるはずです。
影響するかと急ぎ度は、組み込み方で分かれる
使い方
急ぎ度
やること
Javaのアプリでポリシーエンフォーサーを使う
今日
部品の版を見て、26.0.10より前なら上げる日を決める
Keycloakのサーバーが26.6.4より前
今日
版を確認し、最新の26.8.1へ上げる日を決める。JWT Authorization Grantを使っていれば最優先
Red Hat build of Keycloakの26.4.13より前・26.6.4より前
今日
Red Hatの修正版へ上げる日を決める
サーバーが26.6.4以降で、ポリシーエンフォーサーを使わない
対応済み
届いた通知を確かめて閉じる
製品に組み込まれたKeycloakを使う
製品の提供元しだい
提供元に、組み込んだ版と修正の予定を聞く
ポリシーエンフォーサーと26.6.4より前のサーバーをどちらも「今日」にしたのは、どちらもログインできる利用者やクライアントの資格情報を持つ者から、権限の確認をすり抜けられるからです。サーバーの側のCVE-2026-11800は、JWT Authorization Grantを使っていなければ当たりませんが、使っているかの確認に時間はかかりません。
版を確かめて、登録の入口を絞る手順
Keycloakの管理画面の「サーバー情報」で、サーバーの版を確かめます。委託先が運用していれば、版と最後に上げた日を聞きましょう。
Javaのアプリの依存関係から、keycloak-policy-enforcerの版を探します。Mavenなら依存関係の一覧で、GitHubを使っていればDependabotの通知の画面でも見られます。26.0.10より前なら、アプリの担当と上げる日を決めます。
26.6.4より前のサーバーは、移行の手引きを読んでから、最新の26.8.1へ上げます。間の版も含めた変更点を、検証の環境で先に試します。
各クライアントの「有効なリダイレクトURI」にワイルドカードが無いかを見て、あれば1つずつのURIに書き換えます。
クライアントの登録の入口（動的なクライアント登録）を使っていないなら止め、使うなら、登録できる相手を信頼するホストの設定で絞ります。止めたクライアントがある場合は、古い登録用のトークンが残っていないかも確かめます。
