CVE-2026-18963 Keycloak の脆弱性｜影響範囲と対処

はじめに

Keycloak および Red Hat build of Keycloak に、パスワードリセット処理を担う reset-credentials フローの状態検証不備に起因する脆弱性 CVE-2026-18963 が公開されました。Red Hat は、認証されていない攻撃者が、本来必要なメール確認リンクをクリックさせることなくパスワードリセット処理を進め、対象ユーザーの新しい認証情報を直接設定できる可能性があると説明しています。

Red Hat は本脆弱性の深刻度を Critical と評価し、CNA として CVSS v3.1 基本スコア 9.1 を割り当てています。一方で NVD 側は執筆時点で Awaiting Enrichment の状態であり、NVD 独自のスコアは提供されていません。認証も利用者操作も不要という評価であるため、Keycloak を認証基盤として運用している環境では、影響有無の切り分けを早い段階で行う価値があります。

本記事では、コミュニティ版 Keycloak と Red Hat build of Keycloak を明確に分けたうえで、公式情報から確認できる修正済みリリース、自環境の確認手順、暫定対策の位置づけ、そして脆弱性スキャナーで検出されない場合の判断について整理します。

結論として、最初に確認すべきはバージョン番号ではなく、運用している製品系列と配布形態です。コミュニティ版であれば修正が収録された 26.7.2 系などへ、Red Hat build of Keycloak であれば 26.4.15 または 26.6.6 の該当パッケージ・イメージへ更新することが恒久対策になります。直ちに更新できない場合は、Red Hat が案内するとおり、すべての Realm で「Forgot password」を無効化する暫定対策を検討します。

CVE-2026-18963 とは

本脆弱性は、Keycloak のパスワード再設定機能そのものが持つ状態遷移の検証不備です。ここでは、防御側が影響を判断するために必要な範囲で仕組みを整理します。

通常のパスワードリセットフローとメール確認リンクの役割

Keycloak の「Forgot password」は、ログイン画面から利用者がユーザー名またはメールアドレスを入力し、登録済みアドレス宛に送られたリンクを開いてから新しいパスワードを設定する流れで動作します。この設計では、メールを受信して確認リンクを開けることが、本人であることの証明を担っています。

言い換えると、リンクを開く工程がなくなった時点で、この機能は「ユーザー名を知っている誰か」が任意のアカウントのパスワードを設定できる仕組みに変わります。認証機能の一部でありながら、認証を経由せずに到達できる画面である点が、この種の脆弱性の影響を大きくします。

reset-credentials フローの状態検証不備と CWE-640

Red Hat は、根本原因を reset-credentials 認証フロー内の不適切な状態検証であると説明しています。分類は CWE-640（Weak Password Recovery Mechanism for Forgotten Password）です。

参考: Red Hat CVE-2026-18963
“The vulnerability’s root cause is improper state validation within the reset-credentials authentication flow.”
（本脆弱性の根本原因は、reset-credentials 認証フロー内の不適切な状態検証です。）
https://access.redhat.com/security/cve/CVE-2026-18963

コミュニティ側の修正内容は、GitHub の Issue #51833 と、main ブランチへの移植 PR #51844 から輪郭を確認できます。PR で変更されているのは DefaultAuthenticationFlow.java、ResetCredentialEmail.java、およびリグレッションテストの 3 ファイルで、認証セレクターの状態を実行 ID に紐付ける修正と、リセットメールの処理でアクショントークンによるユーザー識別を必要とする修正が含まれています。防御側の理解としては、フローの途中状態が本来のトークンと結び付いていなかった点が修正されたと捉えれば十分です。本記事では、具体的なリクエスト内容や再現手順は扱いません。

CVSS の読み方と評価元の違い

スコアは評価元によって扱いが異なります。執筆時点の状況は次のとおりです。

広く引用されている 9.1 は Red Hat が CNA として付与した値であり、NVD による評価ではありません。社内報告で出典を書く場合は、「NVD の CVSS 9.1」ではなく「Red Hat（CNA）評価の CVSS 9.1」と記載しておくと、後から NVD の enrichment が完了してスコアが更新された際にも整合が崩れません。

可用性への影響が None でも優先度が高い理由

ベクターの末尾は A:N であり、可用性への影響は None と評価されています。サービス停止を伴わないため、可用性を重視する運用ではスコアの読み方を誤りやすい部分です。

ただし本脆弱性で成立するのは、機密性と完全性の両方が High の結果、すなわちアカウントの制御です。Keycloak は複数のアプリケーションへ ID を発行する立場にあるため、Keycloak 上のアカウントが奪われた場合、影響は Keycloak 自身にとどまらず、そのアカウントで認証している下流のシステムへ波及します。可用性影響がないことは、対応を後回しにしてよい根拠にはなりません。

Keycloak の影響範囲と修正版

影響範囲を判断するうえで重要なのは、コミュニティ版 Keycloak と Red Hat build of Keycloak（RHBK）を同じ表に並べないことです。両者はリリース番号の体系も、修正が届く経路も異なります。

コミュニティ版 Keycloak の修正収録リリース

Keycloak 公式の 26.7.2 リリース情報（2026 年 8 月 19 日公開）では、Security fixes の一覧に Issue #51833 として CVE-2026-18963 が含まれています。また、同 Issue には修正が収録されたリリースを示すラベルとして 26.4.15、26.6.6、26.7.2 が付与されています。

ここで注意したいのは、公式情報が示しているのは「修正が収録されたリリース」であって、「影響を受ける全バージョンの範囲」ではないという点です。執筆時点で、コミュニティ版について影響バージョン範囲を明示した一次情報は確認できません。したがって「26.7.2 未満のすべてが影響を受ける」と一括で断定することは避け、自環境のバージョンが上記の修正収録リリース以降であるかどうかで判断することをおすすめします。

なお、main ブランチへ修正を移植する PR #51844 は、執筆時点でまだマージされていません。将来の 26.8 系以降がどのリリースから修正を含むかについては、公開時点で Keycloak 公式のリリース情報を確認してください。

Red Hat build of Keycloak の修正版と RHSA

Red Hat は 2026 年 8 月 18 日付で、26.4 系と 26.6 系に対して 4 件の RHSA を公開しています。スタンドアロンパッケージ向けと OpenShift 向けイメージが別の RHSA に分かれているため、自環境の配布形態に対応する側を確認する必要があります。

表のとおり、パッケージ側は 26.4.15-1、26.6.6-1 という rpm バージョンで表現されるのに対し、コンテナイメージ側は 26.4-23、26.6-12 というビルド番号で表現されます。「26.4.15」「26.6.6」という数字だけを見てイメージの新旧を判断すると、確認対象を取り違えます。イメージについては、RHSA に列挙されている digest との照合が適しています。

NVD の Affected Products 表を読むときの注意

NVD の CVE 詳細ページにある Affected Products は、Red Hat が提供したデータをもとに「Unaffected」と閾値を組み合わせた形式で表示されています。たとえば「Unaffected 26.4.15-1 < *（rpm）」という行は、26.4.15-1 以降が影響を受けないという意味であり、行そのものが影響を受ける製品の一覧という意味ではありません。

一覧に Unaffected と表示された製品名だけを拾うと、「該当製品は影響なし」と読み違えやすい構造になっています。Red Hat の CVE ページと 4 件の RHSA を突き合わせて、製品・配布形態・修正ビルドの対応関係で判断してください。

自環境への影響を確認する流れ

ここまでの整理を踏まえ、実務での確認順序をまとめます。バージョン照合の前に製品系列を確定させることが、手戻りを減らす近道です。

# 稼働中の Pod が参照しているイメージ tag
oc get pods -n NAMESPACE -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.spec.containers[*].image}{"\n"}{end}'

# 実際に起動しているイメージの digest
oc get pods -n NAMESPACE -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.imageID}{"\n"}{end}{end}'

# Operator で管理している場合の CSV バージョン
oc get csv -n NAMESPACE

「対象外」と「攻撃経路を抑えている状態」を混同しない

確認の結果、バージョンが古いものの「Forgot password」がすでに無効だったというケースがあります。この状態は Red Hat が示す暫定対策と実質的に同じですが、判定としては分けて扱うことをおすすめします。

修正済み

ソフトウェア自体が修正収録リリースへ更新されている状態です。設定変更に依存せず、機能を有効に戻しても本 CVE の影響を受けません。

攻撃経路を一時的に抑えている状態

脆弱なコードは残ったまま、設定によって到達経路を塞いでいる状態です。設定の戻し忘れや、新規に作成した Realm の既定値によって、意図せず影響を受ける状態へ戻る可能性があります。

後者を「対象外」として台帳に記録すると、更新対象から外れたまま残り続けます。管理上は未対応として扱い、更新計画に載せることをおすすめします。

MFA を設定している場合の扱い

Red Hat は「any user account」「full access」という表現で影響を説明していますが、多要素認証や WebAuthn を組み合わせた構成、あるいは Reset Credentials フローをカスタマイズした構成で挙動がどう変わるかについて、執筆時点の公式情報に個別の記載は確認できません。

したがって、MFA を設定しているから影響を受けない、という判断は公式情報からは導けません。逆に、MFA が必ず回避されると断定できる情報も確認できません。自環境の認証フロー構成に依存する部分は、確認できない範囲として扱い、更新を前提に計画することが安全側の判断になります。

スキャナーで検出されない場合の注意

本件は、脆弱性スキャナーの結果だけで対象外と判断することの危うさが表面化した事例です。執筆時点で確認できる状況を整理します。

GitHub Advisory Database のメタデータが欠けている

本 CVE に対応する GitHub Advisory は GHSA-4gv3-mc9p-5wqc です。執筆時点でこの Advisory は Unreviewed 区分であり、Package は「No package listed」、Affected versions と Patched versions はいずれも Unknown と表示されています。Advisory ページには、対応エコシステムのパッケージと影響・修正バージョンが揃っていないため Dependabot のアラート対象にならない旨も明記されています。

参考: GitHub Advisory Database GHSA-4gv3-mc9p-5wqc
“Dependabot alerts are not supported on this advisory”
（この Advisory では Dependabot のアラートがサポートされません。）
https://github.com/advisories/GHSA-4gv3-mc9p-5wqc

GitHub Advisory Database を参照するスキャナーは、パッケージ名と影響バージョン範囲を突き合わせて検出を行います。その情報が欠けている以上、対象コンポーネントを正しく検出していても、CVE として報告されない状態になり得ます。

公開 PR で報告された Trivy の未検出

この点については、GitHub Advisory Database へメタデータ追加を提案する公開 PR #9208 が 2026 年 8 月 26 日に提出されています。これは Keycloak や Red Hat による公式の検証結果ではなく、第三者による公開報告である点を前提に読む必要があります。

PR では、対象の Maven コンポーネントが org.keycloak:keycloak-services であること、quay.io/keycloak/keycloak:26.7.0 と Trivy 0.74.0 の組み合わせでコンポーネント自体は正しく識別されたにもかかわらず本 CVE が報告されなかったこと、そして 26.7.2 を修正版としてメタデータに追加する提案が記載されています。

参考: github/advisory-database PR #9208
“The advisory currently has no affected package or version metadata”
（この Advisory には現在、影響パッケージおよびバージョンのメタデータがありません。）
https://github.com/github/advisory-database/pull/9208

なお、この PR は執筆時点で未マージであり、レビューでは 26.4 系と 26.6 系についても範囲を追加すべきではないかという指摘が付いています。提案されているバージョン範囲がそのまま確定した影響範囲を意味するわけではないため、この PR の内容を根拠に影響範囲を断定することは避けてください。

スキャナー結果と一次情報を併用する

NVD が Awaiting Enrichment であること、GHSA のメタデータが欠けていることは、いずれも脆弱性データベースの整備が公開に追いついていない状態を示しています。スキャナーが検出しなかったことは、影響を受けないことの証明にはなりません。

• 公開直後の CVE は、データベース整備の遅れによる false negative があり得ると想定する
• 検出結果がゼロでも、製品名、コンポーネント、実際のバージョンをベンダー Advisory と直接照合する
• SBOM やコンテナスキャンの結果は、ベンダー Advisory と併用して判断材料にする
• 重大な CVE については、スキャナー任せにせず、公開から一定期間後に再スキャンして差分を確認する

更新と暫定対策

恒久対策は修正版への更新です。暫定対策は、更新までの時間を確保するための措置として位置づけます。

更新前のバックアップ

4 件の RHSA はいずれも、更新前に既存の導入環境をバックアップするよう案内しています。対象には、アプリケーション、設定ファイル、データベースおよびデータベース設定が含まれます。カスタムテーマや独自 Provider を配置している場合は、それらも保全対象に含めることをおすすめします。

参考: RHSA-2026:56520
“Before applying the update, back up your existing installation”
（更新を適用する前に、既存の導入環境をバックアップしてください。）
https://access.redhat.com/errata/RHSA-2026:56520

クラスター構成や Operator 管理の環境では、更新順序とローリング更新の可否が構成に依存します。データベーススキーマの変更を伴う更新もあるため、更新によって停止やスキーマ変更が一切発生しないとは限りません。適用前に、対象バージョンの Upgrading Guide で移行時の変更点を確認してください。

特にコミュニティ版で 26.7.2 へ更新する場合、レガシーな client-initiated account linking エンドポイントが既定で無効化されるという破壊的変更が含まれています。該当エンドポイントを利用しているアプリケーションがある環境では、更新計画に影響します。

参考: Keycloak Upgrading Guide
“The deprecated legacy client-initiated account linking endpoint”
（非推奨のレガシーな client-initiated account linking エンドポイント。26.7.2 の破壊的変更として、既定で無効になった旨が記載されています。）
https://www.keycloak.org/docs/latest/upgrading/index.html

全 Realm で「Forgot password」を無効化する

直ちに更新できない場合、Red Hat はすべての Realm で「Forgot password」機能を無効化する暫定対策を案内しています。管理コンソールでの操作パスは Realm settings → Login → Forgot password → Off です。

一部の Realm だけを対象にすると、残った Realm が攻撃経路として残ります。Realm を動的に作成している環境では、作成テンプレートや自動化スクリプトの既定値も併せて見直すことをおすすめします。

暫定対策を適用すると、利用者が自分でパスワードを再設定できなくなります。ヘルプデスクの問い合わせが増えるため、適用前に周知と体制の準備を進めておくと混乱を抑えられます。

セルフサービス停止中の代替運用

セルフサービスによるパスワードリセットが使えない期間は、代替手段を用意しておく必要があります。運用設計として、次のような観点を整理しておくと移行がスムーズです。

• ヘルプデスクでの本人確認手順と、確認に用いる情報の定義
• 管理者による認証情報の再設定を、誰がどの権限で実施するかの取り決め
• 代替運用の期間中に発生する操作の記録方法
• 暫定対策であることを踏まえた、更新完了までの期限設定

本人確認の運用が緩いと、脆弱性への対処のために導入した代替手段が、別の経路でのアカウント乗っ取りを招く可能性があります。手順の明文化を先に済ませておくことをおすすめします。

外部公開の制限は補助策にとどまる

Keycloak のログイン画面をインターネットから遮断する、あるいはリバースプロキシーでパスを制限するといった対応は、攻撃者の到達範囲を狭める効果があります。ただし、これは Red Hat が案内している暫定対策そのものではなく、修正版への更新の代替にもなりません。

社内からのみアクセスできる構成であっても、内部からの攻撃や、侵害された端末を経由した攻撃の可能性は残ります。公開範囲の制限は、更新と暫定対策に加えて実施する補助策として位置づけてください。

適用後に確認すること

更新を適用した後は、意図したバージョンで稼働していること、および認証機能が正常であることを確認します。特にクラスター構成では、一部のノードだけが更新されていない状態に気付きにくいため、実際に稼働している状態を見る確認方法が有効です。

悪用状況の扱い

執筆時点で、本 CVE が CISA KEV カタログへ掲載されていることは確認できません。また、Red Hat および Keycloak の公式情報から、実際の攻撃で悪用されていることを示す記述も確認できません。第三者の脆弱性情報サイトの間では、公開されたコードの有無について記述が分かれています。

KEV への未掲載は、悪用されていないことの証明ではなく、緊急性が低いことの根拠でもありません。認証不要かつ利用者操作不要という評価がされている以上、悪用情報の有無にかかわらず、更新を前提とした計画で進めることをおすすめします。

まとめ

CVE-2026-18963 は、パスワードリセットという「認証を経ずに到達できる機能」の状態検証が不十分だったことに起因する脆弱性です。影響判断でつまずきやすいのは、バージョン番号そのものではなく、コミュニティ版と Red Hat build の区別、そして配布形態ごとに異なるバージョン表記でした。公開直後の脆弱性データベースが未整備であることも重なり、スキャナーの結果だけでは判断できない状況になっています。

• 最初に確認すべきは製品系列と配布形態、次に実バージョン
• 公式に確認できるのは修正収録リリースであり、影響範囲の全体ではない
• コンテナイメージは tag ではなく digest で RHSA と照合する
• 暫定対策は一部ではなくすべての Realm へ適用する
• 機能無効の状態は「対象外」ではなく未対応として管理する
• スキャナーの未検出は影響なしの根拠にならない
• 更新後は digest、ログイン、リセット動作、イベント記録まで確認する

以上、最後までお読みいただきありがとうございました。