--- title: "Keycloakの脆弱性対応の手順：2026年のCVEと修正版・更新判定・監視の実装" url: "https://www.issoh.co.jp/tech/details/19094/" published: 2026-10-30 updated: 2026-10-30 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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のセキュリティポリシー](https://www.keycloak.org/security)は、修正を現行の`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との違いと連携手順](https://www.issoh.co.jp/tech/details/7663/)で解説しています。 ### CVE-2026-9800：Policy Enforcer認可バイパスと修正26.6.4 [GHSA-f5p5-6xmx-p252（CVE-2026-9800）](https://github.com/advisories/GHSA-f5p5-6xmx-p252)は、Policy Enforcerのパス比較の誤りです。ログイン済みの利用者なら誰でも、アクセス拒否時の転送先として設定したページのパスを、URLのパスセグメントかクエリパラメータに含めるだけで、ロール・スコープ・UMAの権限チェックをすべて迂回できます。CVSS 3.1は8.1（ネットワーク経由・低い権限で成立・機密性と完全性に高い影響）です。 転送先とは、[policy enforcerの設定](https://www.keycloak.org/securing-apps/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）](https://github.com/advisories/GHSA-v3f7-2p4r-mwfw)も直っています。こちらは`manage-client`権限を持つ管理者か、クライアント登録エンドポイントを使える主体が前提です。悪用の報告は、2026年10月30日時点でどちらのアドバイザリにも記載がありません。 ### CVE-2026-18963のパスワード再設定の乗っ取りと暫定回避策 2026年に修正された中で最も重いのが、26.7.2（8月19日公開）で直った[CVE-2026-18963](https://github.com/keycloak/keycloak/issues/51833)です。パスワード再設定（reset-credentials）フローの状態検証が不十分で、認証なしの攻撃者がメールの確認リンクを経ずに他人のパスワードを変え、アカウントを乗っ取れます。 [Red HatのCVEページ](https://access.redhat.com/security/cve/CVE-2026-18963)は深刻度をCritical、CVSS 3.1を9.1としています。事前の認証も利用者の操作も要りません。同ページが示す暫定回避策は、全レルムで管理コンソールの「Realm settings → Login → Forgot password」をOffにすることです。利用者が自分でパスワードを戻せなくなるため、問い合わせ窓口での再設定の手順を先に決めてから切り替えてください。 この脆弱性はKeycloakのリポジトリのセキュリティアドバイザリ一覧には載っておらず、リリースノートとissueにだけ記載があります。アドバイザリ一覧だけを見ていると見落とす種類の情報です。 ### 26.6.4から26.8.1までの修正版ごとのCVE件数と公開日 下の表は、[KeycloakのGitHubリリース](https://github.com/keycloak/keycloak/releases/tag/26.8.1)の本文に記載された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の版を表示します。公式コンテナでは[コンテナのガイド](https://www.keycloak.org/server/containers)のとおり`/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のデータベース設定と使い方](https://www.issoh.co.jp/tech/details/3293/)で確認できます。 ### keycloak-policy-enforcerのJava依存版をMavenで確認 アプリ側のライブラリは、サーバーとは独立してリリースされます。[Upgrading Guide](https://www.keycloak.org/docs/latest/upgrading/index.html)も、サーバーの更新とは別の工程として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](https://central.sonatype.com/artifact/org.keycloak/keycloak-policy-enforcer)での2026年10月30日時点の最新は26.0.12でした。ライブラリの変更履歴は[keycloak-clientのリリース](https://github.com/keycloak/keycloak-client/releases/tag/26.0.10)で追えます。Spring Bootなどで依存関係を親のBOMに任せている場合は、`pom.xml`に版が書かれていなくても古い版が入ることがあるため、必ずコマンドの出力で判定してください。 ## 修正版へのアップグレード手順とローリング更新できるかの判定コマンド 版の確認で対象と分かったら、更新に進みます。Keycloakは更新時にデータベースのスキーマを書き換えるため、手順を誤ると元の版に戻せません。 ### DBのバックアップから新しい版の起動までのアップグレード手順 Upgrading Guideの手順を、作業の順に並べると次のとおりです。 1. 移行ガイドで、現行の版から新しい版までの変更点を読む 2. ローリング更新ができない場合（マイナー版以上の更新など）はKeycloakを止める 3. 設定ファイルとテーマなど、現行のインストールを退避する 4. データベースを、そのデータベース製品の手順でバックアップする 5. 新しい版を、同じデータベースにつないで起動する スキーマの移行は起動時に自動で行われる処理です。ただし、レコードが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のガイド](https://www.keycloak.org/server/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のドキュメント](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts)は、GitHubが審査したアドバイザリでなければアラートは出ないと明記しています。つまりDependabotだけで監視していた組織には、修正版の公開から4か月間、何も通知されなかったことになります。 情報源は、早い順に次のように使い分けます。 - KeycloakのGitHubリリースノート：修正版の公開と同時にCVE番号が載る。CVE-2026-18963のようにここにしか載らないものもある - [リポジトリのセキュリティアドバイザリ](https://github.com/keycloak/keycloak/security/advisories)：対象版と修正版の範囲が機械的に読める - Red HatのCVEページ：深刻度の評価と暫定回避策が載ることがある - GitHub Advisory Database・[NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-9800)：遅れて載る。脆弱性管理ツールの多くはここを見ている 実務でまず押さえるのは1つ目だけで足ります。CVE番号の読み方や採番の仕組みは[CVE（共通脆弱性識別子）とは](https://www.issoh.co.jp/tech/details/5092/)にまとめています。 ### 稼働中の版より新しいリリースの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](https://docs.github.com/en/rest/security-advisories/repository-advisories)も見れば、対象版の範囲まで自動で照合できます。 ## 2週間ごとの修正版に追従できない組織が選ぶ運用体制の判断基準 表のとおり、OSS版のKeycloakは2週間前後で修正版が出て、旧系列には配布物が出ません。この周期に人と仕組みが合うかどうかで、OSS版を使い続けてよいかが決まります。 ### 最新系列への追従をCI/CDで回せる組織だけがOSS版を使い続ける条件 OSS版を使い続けてよいのは、次の3つがそろう組織です。検証環境で新しい版を起動して主要なログインフローを自動テストできること、イメージのタグを書き換えるだけで本番へ出せること、系列をまたぐ更新で停止時間を取れること。この3つがあれば、修正版の公開から1〜2週間で本番へ反映できます。 反対に、更新のたびに手作業で検証し、停止の調整に1か月以上かかる組織では、OSS版は採用しないと判断してください。カスタムのテーマや認証の拡張（SPI）を多く入れている場合も、更新ごとの検証が重くなるので同じ扱いです。CVE-2026-18963のように認証なしで乗っ取れる脆弱性が年に1件でも出る以上、反映が遅い体制で認証基盤を自前で持つのは割に合いません。 ### 旧系列を保つ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版との違い・サポート範囲](https://www.issoh.co.jp/column/details/18802/)で整理しています。 サーバーの運用そのものを手放すなら、IDaaSへの移行や、軽量なセルフホスト製品への切り替えも候補です。後者の例は[FusionAuthとは？Keycloakとの選び分け](https://www.issoh.co.jp/tech/details/18601/)で比べています。どれを選ぶにしても、アプリ側の認可の置き場所とトークンの扱いは引き続き設計の対象です。更新の自動化やIDaaSへの移行の設計を外部に任せたい場合は、一創の[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)で、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不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で詳しく扱っています。 ## 関連記事 - [Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】](https://www.issoh.co.jp/tech/details/7663/)：Keycloakの機能と他製品との違いを確認できます。 - [Keycloakのデータベース設定と使い方｜PostgreSQL接続・対応DB・バックアップから権限モデルまで](https://www.issoh.co.jp/tech/details/3293/)：更新前のバックアップとDB接続の設定を確かめられます。 - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】](https://www.issoh.co.jp/column/details/13631/)：自前運用とIDaaSを比べる際の前提知識です。 - [OIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説](https://www.issoh.co.jp/tech/details/6532/)：アプリ側でトークンを検証する手順の基礎です。 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：CVSSの読み方と修正までの流れを押さえられます。 --- 出典: [Keycloakの脆弱性対応の手順：2026年のCVEと修正版・更新判定・監視の実装]()（株式会社一創）