KeycloakのSAML署名検証回避を修正 26.8.2への更新と認証経路の点検

Keycloakの上流版26.8.2では、SAMLのHTTP-Redirectバインディングで署名検証を回避し、外部のIDプロバイダーと連携する利用者になりすませる問題が修正されました。CVE-2026-117691です。KeycloakをSAMLの仲介に使う組織は修正版へ更新し、通常のログインが成功することに加え、署名されていない応答が拒否されることを確認してください。アプリ側がOpenID Connect（OIDC）しか使っていなくても、Keycloakから外部のIDプロバイダーへの接続にSAMLを使っていれば点検対象です。

Keycloak 26.8.2の公式リリースは2026年11月5日付で、同じ版に複数のセキュリティ修正を載せています。本記事はそのうち、外部認証の結果を受け取る境界に関わるCVE-2026-117691を扱います。Red HatのCVE-2026-117691解説では同CVEのCVSS 3.1基本値を9.1、Red Hatとしての影響評価をImportantとしています。これは二つの異なる評価の表記であり、リリースに含まれるすべての修正に同じ数値が付くという意味ではありません。参照した開発元の資料は、個々の組織で侵害が起きたと報告するものではありません。

検証に使う値とログインに使う値が食い違う

SAMLの仲介構成では、利用者の認証を外部IDプロバイダーが行い、Keycloakはその結果を受けて自分の側でセッションを作ります。HTTP-Redirectでは、ブラウザーを介して渡されたURLのクエリにSAMLメッセージや署名に関わる値が含まれます。署名を調べる処理と、認証結果を読み取る処理が同じメッセージを参照していることが前提です。署名の計算自体が正しくても、署名と異なるメッセージでログインを成立させれば、署名は本人確認の根拠になりません。

KeycloakのSAML署名検証に関する修正記録とRed Hatの説明によると、脆弱な処理では、URLでパーセントエンコードされたパラメーター名をメッセージの処理側が解釈する一方、署名の確認側はその名前を同じ形で扱いませんでした。その違いを利用すると、検証を通ったメッセージとは別の、署名されていないSAMLメッセージをログイン処理に使わせることができます。署名鍵そのものを窃取する攻撃とは異なるため、鍵の交換だけではこの不一致は解消しません。

なりすましが成立すると、対象の利用者としてアクセスできる機能は、そのアカウントに結び付く役割や利用先によって変わります。Keycloakに登録されたすべてのアカウントや、すべての連携方法が同じように影響を受けるとみなすのではなく、どの外部IDプロバイダーの認証が、どの利用者とアプリに対応するかを確認します。アプリの管理者や業務用の強い権限を持つ利用者が連携対象に含まれる場合は、一般利用者だけの構成よりも調査の優先度が上がります。

アプリから外部IDプロバイダーまでの経路を棚卸しする

調査は利用者が開くアプリから始めます。たとえば社内ポータルがOIDCでKeycloakにつながり、Keycloakは別組織の認証基盤へSAMLで接続する構成があります。このとき社内ポータルの設定一覧にSAMLがなくても、外部認証の応答を受け取るのはKeycloakです。アプリごとの認証方式を見た後、レルムごとの外部IDプロバイダー、そこで使うバインディング、そこから利用できるアプリを一つの対応表にします。

次に、ログイン要求をどの方式で送るかと、認証結果をどの方式で受けるかを区別します。SAMLの設定にRedirectが一つ見つかったというだけでは、その設定が今回の受信経路を示すとは限りません。管理画面と連携先の設定を見比べ、実際に使われている連携の別名や応答を受け取る入口を確認します。連携先の設定を担当する組織が別にある場合は、Keycloak側の設定だけで経路を確定せず、相手側の担当者と照合します。

古い連携を止めたつもりの環境では、ログイン画面からボタンを隠したことと、受信経路を無効にしたことを区別します。テスト用のレルム、買収した組織の旧ログイン入口、移行中に残した予備ホストも、外部から到達できるなら確認します。一方、SAMLを全く利用しない構成までこのCVEの影響と決めつける必要はありません。ここでの目的は、このCVEの条件を満たす経路を見つけることであり、26.8.2のほかの修正の適用要否は別に判断します。

上流版と製品版の修正を分けて追う

Keycloakプロジェクトが公開する上流版では26.8.2のリリース情報を起点にします。Red Hatなどが提供する製品版では、上流の数字だけを見て、実行中の製品が修正済みか判断しないでください。供給元の告知で該当する製品系列と更新先を確認し、コンテナであれば実際に配備したイメージの版やダイジェストにひも付けます。上流版の配布物を製品版の環境へそのまま入れる前提にはしません。

更新の作業単位は、コードを取得したリポジトリではなく、認証を受けるインスタンスです。運用中のクラスタでは、利用者の入口だけでなく、外部IDプロバイダーが戻り先として使うホストが、どのノードへ接続されるかも確かめます。構成管理の記述が更新されても、古いイメージのPodが稼働し続けていれば、そのPodに振り分けられる要求は修正されていません。試験したノードを特定できるよう、更新の記録にイメージと配備の識別子を残します。

一部ずつ更新する場合、古いノードと新しいノードが同じ入口の背後にある期間を把握します。すべてのノードに到達できる状況では、ブラウザーから一度正常にログインできただけでは確認が足りません。旧ノードが入口から外れたことと、障害時の自動復旧が旧成果物を再配備しないことまで確認します。認証基盤の更新では、接続先の切り替えが業務アプリ全体へ波及するため、基盤と代表的な利用アプリの担当者で、正常と異常の判定を事前に合わせておきます。

更新後は署名が正しい場合と拒否される場合を試す

検証環境には、本番とは別のIDプロバイダーと試験専用の利用者を用意します。まず正規の署名を付けた応答で、外部認証からアプリへのログインまで通ることを確認します。単にKeycloakの画面に進めるかではなく、アプリが受け取った利用者の識別子と権限が、試験用アカウントの設定に合っていることまで見ます。異なる連携先を持つ複数のレルムがある場合は、代表例だけでなく、署名の設定や認証の流れが異なるものも試します。

次に、署名がない、または信頼していない鍵で署名された応答が、セッションを作らず拒否されることを確かめます。入力の表現が違う場合も署名を確認したメッセージと実際に読むメッセージが同じであることは、開発側で回帰テストを持つ際の観点です。自分で構成を試す場合は管理下の検証環境で行い、公開中の本番認証基盤に不正形式の入力を送って影響を判定する必要はありません。通常のログインが失敗する状態で拒否だけを見ても、防御が意図どおり機能したとは判定できません。

更新を待つ間に、影響するSAML連携を一時停止できるかは業務に応じて判断します。これは露出を減らすための運用上の選択であり、公式の修正版の代替ではありません。たとえば一つの連携が停止すると全従業員のログインができなくなる場合は、停止を決める前に別の正規の認証経路を確認します。反対に、既に使っていない連携なら、残しておく理由と到達可能性を確認し、不要な場合は有効な入口を減らせます。署名チェックを無効にして更新後の互換性を確保する方法は、今回守るべき境界を崩します。

アプリが受け取ったIDトークンの署名が正しいことも、この問題が起きなかった証明にはなりません。脆弱な仲介処理が外部の利用者を誤って受け入れた後、Keycloakがアプリへ通常どおりトークンを発行するためです。アプリ側の署名検証はそのまま維持し、試験結果には、外部IDプロバイダーの応答をKeycloakが受け入れたかと、その後にアプリのセッションが作られたかを分けて記録します。

過去の確認では二つのログを照合する

パッチは新たななりすましを防ぐための措置です。更新前の認証が正規だったことまでは証明しません。影響する受信経路が存在した期間を定め、外部IDプロバイダー側の認証記録と、Keycloak側のログインやセッション作成の記録を照合します。調査では、タイムゾーン、利用者の対応関係、連携の別名をそろえ、照合できなかった記録を後から追えるようにします。アプリ側の監査記録が残っていれば、その利用者で行われた操作の確認に使えます。

外部IDプロバイダーに対応する記録が見当たらない場合でも、ログの保存期間や既存セッションによる認証の省略など、別の理由がないか確認します。ログだけでなりすましの有無が判断できない場合は、その範囲を明示します。調査でURLやSAMLメッセージを扱う場合は、個人情報や認証に関わる値を含み得るので、問い合わせ票へ生データを貼り付けず、調査担当者だけが確認できる場所に保全します。

同じアカウントが複数のレルムや外部IDプロバイダーに存在する場合は、表示名やメールアドレスだけでログを結合すると、別人の認証を対応付けるおそれがあります。確認に使う識別子は、外部IDプロバイダー内の識別子、Keycloak側の連携先と利用者ID、アプリが記録する主体IDです。ログにその一部しかない場合は、同一の利用者だと断定せず、時刻や対象アプリを添えて確認できる範囲を示します。

運用の完了条件は、影響する認証経路すべてに修正が適用され、許可したログインと拒否すべきログインを別々に確認できていることです。過去に影響する経路が存在したなら、ログの確認範囲と追加調査の要否も別に引き継ぎます。これにより、修正の配備と、更新前に起きたかもしれない不正アクセスの調査を混同せずに済みます。