Cloud Foundry UAAにCVSS 10.0の秘密鍵漏えいの恐れがある脆弱性 CVE-2026-40965、EC鍵利用環境は更新と鍵ローテーションを

セキュリティニュース

投稿日時: 更新日時:

Cloud Foundry UAAにCVSS 10.0の秘密鍵漏えいの恐れがある脆弱性 CVE-2026-40965、EC鍵利用環境は更新と鍵ローテーションを

Cloud Foundry Foundation Security Teamは、Cloud Foundry UAAにおけるEC秘密鍵漏えいの脆弱性 CVE-2026-40965を公表しました。

CVE-2026-40965は、Cloud Foundry UAAの公開エンドポイントである/token_keysから、本来公開されるべきではないEC、楕円曲線暗号の秘密鍵コンポーネントが誤って返却される脆弱性です。CVSS v3.1およびCVSS v4.0はいずれも10.0で、Criticalに分類されています。

影響を受けるのは、JWT署名にEC鍵を利用しているCloud Foundry UAA環境です

この記事のサマリー

  • Cloud Foundry UAAにCVE-2026-40965が公表されました。
  • CVSS v3.1、CVSS v4.0はいずれも10.0です。
  • /token_keysエンドポイントからEC秘密鍵コンポーネントが漏えいする可能性があります。
  • /token_keysは、本来JWT検証用の公開鍵情報を返すためのエンドポイントです。
  • 影響を受けるのは、JWT署名にEC鍵を利用している環境です。
  • RSA鍵構成は影響を受けないと説明されています。
  • 影響バージョンはuaa_release v76.12.0からv78.12.0までです。
  • CF Deploymentではv30.0.0からv56.0.0までが影響対象です。
  • 修正版はuaa_release v78.13.0以上、cf-deployment v56.1.0以上です。
  • 更新後は、漏えいした可能性があるEC署名鍵のローテーションと既存トークンの無効化を検討する必要があります。

何が起きたか

Cloud Foundry公式アドバイザリによると、Cloud Foundry UAA v76.12.0からv78.12.0までに、EC秘密鍵が公開/token_keysエンドポイントから誤って露出する脆弱性が存在します。

/token_keysは、JWT検証に必要な公開鍵情報を提供するためのエンドポイントです。しかし、対象バージョンではEC鍵利用時に秘密鍵コンポーネントが含まれる可能性がありました。

脆弱性の概要

項目 内容
CVE CVE-2026-40965
製品 Cloud Foundry UAA
影響コンポーネント /token_keysエンドポイント
種別 EC秘密鍵の情報漏えい
CVSS v3.1 10.0 Critical
CVSS v4.0 10.0 Critical
攻撃条件 ネットワーク経由、認証不要
影響する鍵構成 JWT署名にEC鍵を利用する構成
影響しない鍵構成 RSA鍵構成
修正版 uaa_release v78.13.0以上、cf-deployment v56.1.0以上

Cloud Foundry公式アドバイザリでは、影響対象としてuaa_release v76.12.0からv78.12.0、CF Deployment v30.0.0からv56.0.0が示されています。

影響を受けるバージョン

製品・リリース 影響バージョン 修正版
uaa_release v76.12.0からv78.12.0まで v78.13.0以上
CF Deployment v30.0.0からv56.0.0まで v56.1.0以上

Cloud Foundryは、uaa_releaseをv78.13.0以上へ更新すること、またCF Deploymentを利用している場合は、uaa_release v78.13.0を含むcf-deployment v56.1.0以上へ更新することを推奨しています。

Cloud Foundry UAAとは

Cloud Foundry UAA、User Account and Authenticationは、Cloud Foundry環境の認証・認可を担うコンポーネントです。

ユーザー認証、OAuth、JWTトークン発行、クライアント認証、管理APIの認可などに関わります。Cloud Foundryを社内PaaS、業務アプリケーション基盤、開発者向けプラットフォームとして利用している場合、UAAは認証基盤の中心になります。

UAAが発行するJWTは、アプリケーションやコンポーネントが利用者やクライアントの権限を確認するために使われます。したがって、JWT署名鍵の秘密鍵が漏えいすると、単なる設定情報の漏えいではなく、認証基盤そのものの信頼性が崩れる恐れがあります。

/token_keysとは

/token_keysは、UAAが発行したJWTを検証するための鍵情報を返すエンドポイントです。

Cloud Foundry UAA APIリファレンスでは、/token_keysはJWTキーの一覧を返すエンドポイントであり、JWTに含まれるkidに基づいて、どの鍵でトークンを検証すべきかを判断するために使われると説明されています。

本来、このエンドポイントで公開されるべきなのは、JWT検証に必要な公開鍵情報です。ところがCVE-2026-40965では、EC鍵をJWT署名に利用している場合に、秘密鍵コンポーネントまでJSONレスポンスに含まれてしまう可能性がありました。

なぜ危険なのか

CVE-2026-40965の危険性は、秘密鍵が漏えいする点にあります。

JWTは、署名によって正当性を確認します。署名鍵の秘密鍵を攻撃者が入手した場合、攻撃者は正規のUAAが発行したように見えるトークンを作成できる可能性があります。

その結果、以下のような影響が考えられます。

想定される影響 内容
JWT偽造 攻撃者が正規トークンに見えるJWTを作成する恐れ
認証回避 偽造トークンにより認証を突破される可能性
権限昇格 管理者や高権限ユーザーを装うトークンが作成される可能性
API不正操作 Cloud Foundry APIや関連サービスに不正アクセスされる恐れ
アプリケーション侵害 UAAトークンを信頼するアプリケーションで不正操作される可能性
監査困難 署名が有効なトークンとして扱われ、異常検知が遅れる可能性

特に、Cloud Foundry上で複数の業務アプリケーションや社内開発基盤を運用している場合、UAAの署名鍵漏えいは基盤全体の認証に影響します。単一アプリケーションの脆弱性ではなく、PaaS全体の信頼境界に関わる問題として扱う必要があります。

EC鍵利用環境のみが影響する理由

Cloud Foundry公式アドバイザリでは、CVE-2026-40965はJWT署名にEC鍵を利用する環境に影響し、RSA鍵構成には影響しないと説明されています。

EC鍵は楕円曲線暗号を使う鍵方式です。JWTのJWK表現では、公開鍵として必要な値と、秘密鍵として扱うべき値が同じJSON構造内に含まれることがあります。

今回の問題は、公開鍵情報だけを返すべき/token_keysレスポンスに、EC秘密鍵コンポーネントが含まれてしまう点です。RSA鍵構成ではこの問題の影響を受けないとされていますが、自社環境でどの鍵方式を使っているかを確認せずに安全と判断すべきではありません。

すぐに実施すべき対応

Step 1:Cloud FoundryとUAAのバージョンを確認する

まず、自社のCloud Foundry環境で利用しているcf-deploymentとuaa_releaseのバージョンを確認してください。

BOSH環境では、以下のような確認が考えられます。

bosh deployments
bosh -d <deployment-name> releases

対象範囲は、本番環境だけではありません。

確認対象 内容
本番Cloud Foundry 外部・社内アプリケーションが稼働している環境
検証環境 本番より古いcf-deploymentが残りやすい環境
開発者向けPaaS 社内開発者が利用する共有基盤
DR環境 更新が遅れやすい待機系
グループ会社環境 独自にCloud Foundryを運用している場合
過去移行環境 旧基盤が停止されず残っている場合

Step 2:EC鍵をJWT署名に使っているか確認する

今回の脆弱性は、JWT署名にEC鍵を使っている場合に影響します。

UAA設定、BOSH変数、identity zone token policyなどで、JWT署名鍵の種類を確認してください。UAA APIリファレンスでは、JWT署名鍵はidentity zoneのtoken policyで指定され、キーIDをactiveKeyIdとして設定することで新規トークン署名に利用されると説明されています。

確認すべき点は以下です。

確認項目 内容
JWT署名鍵の種類 EC鍵かRSA鍵か
activeKeyId 現在トークン署名に使われている鍵ID
keys 過去鍵を含む有効鍵一覧
identity zones 複数ゾーンで別鍵が使われていないか
BOSH variables UAA署名鍵がどこで管理されているか
鍵ローテーション履歴 直近で鍵が更新されているか

Step 3:/token_keysのレスポンスを確認する場合は慎重に扱う

脆弱な環境では、/token_keysに秘密鍵情報が含まれる可能性があります。

内部確認のためにレスポンスを取得する場合でも、出力をチケット、チャット、ログ、メールに貼り付けないでください。取得結果そのものが秘密情報になる可能性があります。

確認する場合は、セキュリティ担当者またはCloud Foundry管理者が、限定された端末と安全な保管場所で実施してください。

curl -s https://<uaa-domain>/token_keys | jq

JWKでEC秘密鍵を示すdなどの値が含まれている場合、秘密鍵漏えいとして扱う必要があります。レスポンスの保存や共有は避け、直ちに更新と鍵ローテーションの手順に進んでください。

Step 4:修正版へ更新する

Cloud Foundry公式アドバイザリは、以下への更新を推奨しています。

利用形態 推奨対応
uaa_releaseを直接管理 v78.13.0以上へ更新
cf-deploymentを利用 v56.1.0以上へ更新
複数デプロイ環境 すべての環境で対象バージョンを確認
検証環境 本番と同様に更新
DR環境 切替時に脆弱環境へ戻らないよう更新

更新前には、BOSHバックアップ、UAAデータベースのバックアップ、復旧手順、メンテナンス時間、認証連携への影響を確認してください。

Step 5:署名鍵をローテーションする

脆弱な状態でEC鍵を利用していた場合、更新だけでは十分ではありません。

すでに/token_keys経由でEC秘密鍵が取得されていた可能性があるため、漏えいした可能性がある署名鍵はローテーションし、古い鍵で署名されたトークンを無効化する対応を検討してください。

UAA APIリファレンスでは、identity zoneのtoken policyに複数鍵を設定でき、activeKeyIdに指定した鍵で新しいトークンを署名すること、過去の署名鍵がkeysに残っている間は既存トークンの検証が継続され、削除するとその鍵で署名されたトークンを無効化できることが説明されています。

運用上は、以下の流れを検討します。

手順 内容
1 修正版へ更新
2 新しい署名鍵を作成
3 activeKeyIdを新しい鍵へ切り替え
4 既存トークンの有効期限と影響を確認
5 漏えいした可能性がある古いEC鍵を削除
6 既存セッションやトークンの再認証を案内
7 アプリケーションやクライアントの認証影響を確認

鍵ローテーションは、ユーザーセッションやAPIクライアントに影響する可能性があります。業務影響を確認したうえで、できるだけ短い時間で実施してください。

Step 6:ログを確認する

公式アドバイザリでは、悪用確認に関する記載は確認できません。一方で、/token_keysは公開鍵取得に使われるエンドポイントのため、通常利用のアクセスも発生し得ます。

確認すべきログは以下です。

ログ 見るべき内容
UAAアクセスログ /token_keysへの大量アクセス、不審な送信元
LB・WAFログ 通常と異なる国・IP・ASNからのアクセス
APIログ 不審なJWTを使ったAPIアクセス
UAA監査ログ 不審なクライアント、ユーザー、スコープ利用
アプリケーションログ 通常外のユーザーIDや権限での操作
認証失敗・成功ログ 異常なトークン利用や認証パターン
管理操作ログ org、space、service broker、route等の変更

/token_keysへのアクセス自体は正当な場合があります。重要なのは、通常とは異なる送信元、短時間の大量アクセス、更新前後の挙動、異常な権限を持つJWTの利用痕跡を合わせて確認することです。

侵害が疑われる場合の対応

脆弱なバージョンでEC鍵を利用しており、/token_keysレスポンスに秘密鍵が含まれていた可能性がある場合は、鍵漏えいインシデントとして扱う必要があります。

確認すべき対応は以下です。

対応 内容
署名鍵ローテーション 漏えい可能性のあるEC鍵を新鍵へ置換
旧鍵削除 旧鍵で署名されたJWTを検証対象から外す
セッション無効化 影響範囲に応じて再ログインを要求
クライアント確認 サービスアカウント、OAuthクライアント、CI/CD連携を確認
高権限操作確認 管理者権限、org manager、space developer等の操作履歴確認
監査ログ保全 UAA、Cloud Controller、Load Balancer、アプリログを保全
外部公開確認 UAAエンドポイントへの到達範囲とアクセス元を確認

秘密鍵が漏えいした場合、攻撃者が後からトークンを偽造する可能性があります。単に不審アクセスが見つからないことだけで安全とは判断せず、鍵そのものを無効化することが重要です。

出典