2026.10.30 セキュリティ

Keycloakの脆弱性対応の手順：2026年のCVEと修正版・更新判定・監視の実装

Keycloakでは2026年6月から10月までの間に、ほぼ2週間おきに脆弱性の修正版が出ています。2026年10月29日には、Policy Enforcerの認可バイパスCVE-2026-9800（CVSS 3.1で8.1）がGitHub Advisory Databaseに掲載されました。ただしこの修正を含む26.6.4の公開は6月26日で、掲載までに要した期間は4か月です。本記事では、2026年に公表された主な脆弱性と修正版、稼働中のサーバーとアプリ側ライブラリの版を確かめるコマンド、ローリング更新ができるかの判定、リリースノートを基準にした監視の仕組みを実装者向けに整理します。記載は2026年10月30日時点の公開情報にもとづきます。

まとめ：Keycloakは最新系列26.8.1へ上げ、リリースノート基準で脆弱性を追う

2026年10月30日時点の最新版は26.8.1（10月13日公開）です。Keycloakのセキュリティポリシーは、修正を現行のmajor.minor系列に入れると定めており、GitHubでリリースとして配布されるのも最新系列だけです。26.6系や26.7系で止めているなら、26.8.1へ上げるのが唯一の確実な対応になります。

サーバーを上げても終わらない場合があります。CVE-2026-9800はアプリに組み込むJavaライブラリkeycloak-policy-enforcerにも影響し、こちらは26.0.10以上へ別途更新が必要です。

監視はDependabotだけに任せないでください。GitHubが審査を終えたアドバイザリでなければアラートは出ず、今回のように数か月遅れます。KeycloakのGitHubリリースノートにはCVE番号が並ぶため、稼働中の版より新しいリリースを定期的に照合する仕組みを置くほうが確実です。この追従を自社で回せない組織は、長期サポートのあるRed Hat build of KeycloakかIDaaSへの切り替えを検討する段階にあります。

2026年に公表されたKeycloakの脆弱性と修正版を系列別に整理

まず、2026年に修正された脆弱性のうち影響の大きいものと、リリースごとの件数を押さえます。Keycloakそのものの機能や他製品との比較はKeycloakとは？Oktaとの違いと連携手順で解説しています。

CVE-2026-9800：Policy Enforcer認可バイパスと修正26.6.4

GHSA-f5p5-6xmx-p252（CVE-2026-9800）は、Policy Enforcerのパス比較の誤りです。ログイン済みの利用者なら誰でも、アクセス拒否時の転送先として設定したページのパスを、URLのパスセグメントかクエリパラメータに含めるだけで、ロール・スコープ・UMAの権限チェックをすべて迂回できます。CVSS 3.1は8.1（ネットワーク経由・低い権限で成立・機密性と完全性に高い影響）です。

転送先とは、policy enforcerの設定にあるon-deny-redirect-toのURLを指します。既定では403を返す設定なので、この項目を入れている構成ほど影響を受けやすいと読めます。修正版は、サーバー側のkeycloak-servicesが26.6.4、アプリ側ライブラリのkeycloak-policy-enforcerが26.0.10です。

同じ26.6.4では、リダイレクトURIの検証を大文字小文字の違いで回避してXSSにつなげるCVE-2026-9086（CVSS 7.3）も直っています。こちらはmanage-client権限を持つ管理者か、クライアント登録エンドポイントを使える主体が前提です。悪用の報告は、2026年10月30日時点でどちらのアドバイザリにも記載がありません。

CVE-2026-18963のパスワード再設定の乗っ取りと暫定回避策

2026年に修正された中で最も重いのが、26.7.2（8月19日公開）で直ったCVE-2026-18963です。パスワード再設定（reset-credentials）フローの状態検証が不十分で、認証なしの攻撃者がメールの確認リンクを経ずに他人のパスワードを変え、アカウントを乗っ取れます。

Red HatのCVEページは深刻度をCritical、CVSS 3.1を9.1としています。事前の認証も利用者の操作も要りません。同ページが示す暫定回避策は、全レルムで管理コンソールの「Realm settings → Login → Forgot password」をOffにすることです。利用者が自分でパスワードを戻せなくなるため、問い合わせ窓口での再設定の手順を先に決めてから切り替えてください。

この脆弱性はKeycloakのリポジトリのセキュリティアドバイザリ一覧には載っておらず、リリースノートとissueにだけ記載があります。アドバイザリ一覧だけを見ていると見落とす種類の情報です。

26.6.4から26.8.1までの修正版ごとのCVE件数と公開日

下の表は、KeycloakのGitHubリリースの本文に記載されたCVE番号の数を、2026年10月30日に集計したものです。依存ライブラリの脆弱性や、過去の修正が不完全だったという言及も含みます。

版	公開日（UTC）	CVE件数	主な修正
26.6.4	2026-06-26	8件	CVE-2026-9800 認可バイパス
26.7.0	2026-07-09	4件	新しい系列の開始
26.7.1	2026-08-05	12件	SAML連携の署名検証の不備
26.7.2	2026-08-19	8件	CVE-2026-18963 乗っ取り
26.7.3	2026-08-31	22件	認証と管理APIの修正多数
26.7.4	2026-09-16	6件	リプレイ防止の迂回
26.7.5	2026-09-30	15件	26.7系で直近の修正
26.8.0	2026-10-01	7件	新しい系列の開始
26.8.1	2026-10-13	22件	管理者権限の昇格ほか

4か月で9回、延べ100件を超えるCVE番号が並びました。26.8.1には、manage-usersだけを委任された管理者がグループ経由でrealm-adminになれるCVE-2026-94000や、X.509のCRL取得でのパストラバーサルCVE-2026-103884が含まれます。「半年に一度まとめて上げる」運用では、常に数十件の既知の脆弱性を抱えたまま動かすことになります。

稼働中のKeycloakとアプリ側ライブラリの版をコマンドで確かめる手順

対応の要否は、サーバーの版とアプリに組み込んだライブラリの版の2つで決まります。両者はリリースの周期も番号の系列も別なので、分けて確かめます。

kc.sh –versionとコンテナのイメージタグでサーバーの版を読み取る

Keycloakのコマンドkc.shには--version（短縮形-V）があり、Keycloak・JVM・OSの版を表示します。公式コンテナではコンテナのガイドのとおり/opt/keycloak/bin/kc.shに置かれています。

# ZIP 配布で動かしている場合（Keycloak のホームディレクトリで実行）
bin/kc.sh --version

# 公式コンテナで動かしている場合
docker exec keycloak /opt/keycloak/bin/kc.sh --version

# Docker Compose の定義に書かれたイメージのタグを確かめる
docker compose images keycloak
grep -n "quay.io/keycloak/keycloak" compose.yaml

イメージをquay.io/keycloak/keycloak:latestで指定している場合、表示される版は最後にイメージを取得した時点のものです。latestは再取得しない限り更新されないため、タグは26.8.1のように固定し、更新はタグの書き換えで行うと版の記録が残ります。データベースの構成やバックアップの取り方はKeycloakのデータベース設定と使い方で確認できます。

keycloak-policy-enforcerのJava依存版をMavenで確認

アプリ側のライブラリは、サーバーとは独立してリリースされます。Upgrading Guideも、サーバーの更新とは別の工程としてAdmin client・Authorization client・Policy enforcerの更新を挙げています。

# Maven：org.keycloak のライブラリと実際に解決された版を表示する
mvn dependency:tree -Dincludes=org.keycloak

# Gradle の場合
./gradlew dependencies --configuration runtimeClasspath | grep org.keycloak

keycloak-policy-enforcerが26.0.10未満なら、CVE-2026-9800の対象です。Maven Centralでの2026年10月30日時点の最新は26.0.12でした。ライブラリの変更履歴はkeycloak-clientのリリースで追えます。Spring Bootなどで依存関係を親のBOMに任せている場合は、pom.xmlに版が書かれていなくても古い版が入ることがあるため、必ずコマンドの出力で判定してください。

修正版へのアップグレード手順とローリング更新できるかの判定コマンド

版の確認で対象と分かったら、更新に進みます。Keycloakは更新時にデータベースのスキーマを書き換えるため、手順を誤ると元の版に戻せません。

DBのバックアップから新しい版の起動までのアップグレード手順

Upgrading Guideの手順を、作業の順に並べると次のとおりです。

移行ガイドで、現行の版から新しい版までの変更点を読む
ローリング更新ができない場合（マイナー版以上の更新など）はKeycloakを止める
設定ファイルとテーマなど、現行のインストールを退避する
データベースを、そのデータベース製品の手順でバックアップする
新しい版を、同じデータベースにつないで起動する

スキーマの移行は起動時に自動で行われる処理です。ただし、レコードが30万件を超えるテーブルへのインデックス作成は移行中には行われず、PostgreSQLなどでは起動後にバックグラウンドで作られます。Keycloakはデータベースの変更を巻き戻せないので、元の版へ戻すときは旧インストールとバックアップの両方の復元が必要です。PostgreSQLなら、作業前に次のように取得しておきます。

# 作業前に取得（カスタム形式。復元は pg_restore で行う）
pg_dump -Fc -h db.example.internal -U keycloak -d keycloak \
  -f keycloak_before_26.8.1.dump

update-compatibilityコマンドの終了コードでローリング更新を判定する

2台以上で動かしている場合、同じmajor.minor系列のパッチ版への更新なら、1台ずつ入れ替えて止めずに更新できます。可否はupdate-compatibilityのガイドにある2つのコマンドで判定します。

# 1. 現行の版で、起動時と同じオプションを付けてメタデータを保存する
bin/kc.sh update-compatibility metadata --file=/tmp/kc-metadata.json \
  --db=postgres --hostname=https://auth.example.com

# 2. 新しい版で、同じオプションを付けて判定する
bin/kc.sh update-compatibility check --file=/tmp/kc-metadata.json \
  --db=postgres --hostname=https://auth.example.com
echo "exit code: $?"

終了コードが0ならローリング更新ができ、3なら全台を止めてから更新する必要があります。1はメタデータの欠損などの想定外のエラー、2はオプションの誤り、4はローリング更新の機能が無効という意味です。ガイドはメタデータの中身ではなく終了コードだけで判断するよう求めているので、CI/CDのパイプラインでは終了コードで分岐させてください。26.7.5から26.8.1のように系列をまたぐ更新は、判定するまでもなく停止が必要になります。入れ替え中に利用者が新旧の版を行き来しないよう、ロードバランサのスティッキーセッションも有効にしておきます。

セキュリティアドバイザリの追い方とGitHub APIで新しいCVEを検知する仕組み

更新の手順が整っても、修正版が出たことに気づけなければ動けません。情報源ごとの遅れ方を知ったうえで、監視の起点を決めます。

GitHub Advisory DatabaseとDependabotの4か月遅延と監視

CVE-2026-9800のアドバイザリは、Keycloakのリポジトリでは2026年6月26日に公開され、GitHub Advisory Databaseへの掲載は10月29日でした。Dependabotのドキュメントは、GitHubが審査したアドバイザリでなければアラートは出ないと明記しています。つまりDependabotだけで監視していた組織には、修正版の公開から4か月間、何も通知されなかったことになります。

情報源は、早い順に次のように使い分けます。

KeycloakのGitHubリリースノート：修正版の公開と同時にCVE番号が載る。CVE-2026-18963のようにここにしか載らないものもある
リポジトリのセキュリティアドバイザリ：対象版と修正版の範囲が機械的に読める
Red HatのCVEページ：深刻度の評価と暫定回避策が載ることがある
GitHub Advisory Database・NVD：遅れて載る。脆弱性管理ツールの多くはここを見ている

実務でまず押さえるのは1つ目だけで足ります。CVE番号の読み方や採番の仕組みはCVE（共通脆弱性識別子）とはにまとめています。

稼働中の版より新しいリリースのCVEをGitHub APIで数えるスクリプト

次のスクリプトは、GitHubのリリース一覧APIを呼び、引数で渡した稼働中の版より新しいリリースと、その本文に載ったCVE番号を表示します。標準ライブラリだけで動き、認証なしでも1時間に60回まで呼べます。

# kc_newer_cves.py：稼働中の版より新しいリリースとCVE番号を列挙する
import json
import re
import sys
import urllib.request

current = tuple(int(x) for x in sys.argv[1].split("."))
url = "https://api.github.com/repos/keycloak/keycloak/releases?per_page=30"
req = urllib.request.Request(url, headers={"Accept": "application/vnd.github+json"})
releases = json.load(urllib.request.urlopen(req, timeout=30))

for r in releases:
    tag = r["tag_name"]
    if not re.fullmatch(r"\d+\.\d+\.\d+", tag):
        continue  # nightly などを除く
    if tuple(int(x) for x in tag.split(".")) <= current:
        continue
    cves = sorted(set(re.findall(r"CVE-\d{4}-\d+", r["body"] or "")))
    print(f'{tag}\t{r["published_at"][:10]}\tCVE {len(cves)}件')

2026年10月30日にpython kc_newer_cves.py 26.7.5で実行すると、26.8.1（CVE 22件）と26.8.0（CVE 7件）の2行が出力されました。何も出力されなければ、稼働中の版が最新版という判定です。週1回のジョブで実行し、出力があればチャットへ通知する形にしておくと、Advisory Databaseの掲載を待たずに気づけます。同じ周期でリポジトリのアドバイザリAPIも見れば、対象版の範囲まで自動で照合できます。

2週間ごとの修正版に追従できない組織が選ぶ運用体制の判断基準

表のとおり、OSS版のKeycloakは2週間前後で修正版が出て、旧系列には配布物が出ません。この周期に人と仕組みが合うかどうかで、OSS版を使い続けてよいかが決まります。

旧系列を保つRed Hat build of KeycloakとIDaaSへの移行判断

Keycloakのセキュリティポリシーは、定期的な更新が難しい場合に長期サポートのあるRed Hat build of Keycloakを勧めています。実際、KeycloakのGitHubには26.6.5以降や26.4系のタグがある一方、リリースとして配布されるのは最新系列だけです。旧系列のまま修正を受けたいなら、サポート契約が前提になります。違いとライセンスはRed Hat build of Keycloakとは：OSS版との違い・サポート範囲で整理しています。

サーバーの運用そのものを手放すなら、IDaaSへの移行や、軽量なセルフホスト製品への切り替えも候補です。後者の例はFusionAuthとは？Keycloakとの選び分けで比べています。どれを選ぶにしても、アプリ側の認可の置き場所とトークンの扱いは引き続き設計の対象です。更新の自動化やIDaaSへの移行の設計を外部に任せたい場合は、一創の認証基盤・ID管理システム開発で、Keycloakの運用見直しから移行まで支援しています。

Keycloakの脆弱性対応で運用担当者からよく受ける質問と回答

Keycloakの更新と脆弱性の確認で、現場から出やすい疑問をまとめました。

Policy Enforcerを使っていなければCVE-2026-9800は対象外ですか？

CVE-2026-9800はPolicy Enforcerによる認可の脆弱性なので、Policy Enforcerを使わずトークンの検証とロールの判定をアプリ側で行っている構成は、この脆弱性の前提を満たしません。ただし、同じ26.6.4ではJWTのアルゴリズム混同による認証バイパスCVE-2026-11800も直っており、こちらはPolicy Enforcerの有無と関係ありません。対象かどうかを個別に判定するより、サーバーを最新系列へ上げるほうが早く確実です。

Red Hat build of Keycloakを使っている場合は何を見ればよいですか？

Red Hat build of Keycloakは独自の版番号と修正版を持つため、OSS版のリリースノートの版番号はそのまま当てはまりません。各CVEのRed Hatのページと、そこからたどれるエラータ（RHSA）で、自社の版に対応する修正版を確かめてください。CVE-2026-9800では、アドバイザリの参照先に複数のRHSAが並んでいます。OSS版とは系列の考え方も違うので、更新計画はRed Hatのサポート期間に合わせて立てます。

更新までの間にできる暫定対策はありますか？

脆弱性ごとに異なります。CVE-2026-18963は、Red Hatが示すとおり全レルムで「Forgot password」をOffにすれば、更新までの間は入口を閉じられます。CVE-2026-9800は、アドバイザリに暫定回避策の記載がありません。暫定対策が無い脆弱性は更新以外に手がないので、WAFで特定のパスを止めるような独自の回避策に時間を使うより、更新の作業を前倒しするほうが確実です。

Docker Composeで動かしているKeycloakはどう更新すればよいですか？

compose.yamlのイメージのタグを新しい版（例：quay.io/keycloak/keycloak:26.8.1）に書き換え、データベースをバックアップしてからdocker compose pullとdocker compose up -dを実行します。カスタムのテーマや拡張を入れたイメージを自前でビルドしている場合は、DockerfileのFROMの版も合わせて上げ、ビルドし直してください。単一コンテナの構成は停止を伴うため、利用の少ない時間帯に行います。

自社のアプリ側でもKeycloakの脆弱性に備えて直すべき点はありますか？

あります。CVE-2026-9800のように認可の判定をKeycloak側の仕組みだけに任せていると、そこが迂回されたときに防ぐ層がありません。重要な操作では、アプリ側でもトークンのロールや所有者を確かめる処理を置いてください。トークンの失効やレート制限まで含めたAPI側の守り方はAPI不正アクセス対策の実装手順で詳しく扱っています。