KEDAは、Kubernetes (コンテナ を動かす基盤)の上で働く、アプリの台数を自動で調整する仕組みです。キューにたまった仕事の数などに合わせて、アプリの台数を増減します。このKEDAに、名前空間の管理者がクラスター全体の管理者と同じ権限を得られる脆弱性 (CVE-2026-77524)が見つかりました。
深刻度を表すCVSSは9.9(Critical)で、直した版の2.21.0は9月23日(日本時間では24日)に出ています。GitHub の脆弱性データベース は日本時間10月16日、この告知を確認済み(GitHub Reviewed)として載せました。KEDAの告知とリリースノート、移行の手引き、米国NVDとCISAの資料で確かめた内容だけを書きます。
KEDAで何が起きるか
Kubernetesのクラスター(サーバーの集まり)は、名前空間という区画に分けて、チームや部署ごとに使えます。KEDAの利用者は、自分の名前空間に2つの設定を置きます。
ScaledObjectは、何を見て、どのアプリを何台まで増やすかを書く設定です。TriggerAuthenticationは、外のサービスに問い合わせるときの認証の方法を書く設定です。
KEDAの本体(オペレーター)は、クラスター全体で台数を変えたり情報を読んだりするため、広い権限を持っています。その権限を使うための身分証にあたるのが、トークン(文字列)です。
HashiCorp Vaultは、パスワードや鍵などの秘密の情報を預かるソフトです。告知によると、利用者はTriggerAuthenticationに、Vaultの送り先を自由に書けました。Kubernetesの認証を選び、使うトークンを指定しないと、オペレーター自身のトークンが使われる作りでした。
その結果、オペレーターは自分のトークンを、利用者が決めた送り先へ送ってしまいました。2025年12月の前回の修正(CVE-2025-68476)は、読み込んだ中身がKubernetesのサービスアカウントのトークンの形かどうかだけを見ていました。オペレーター自身のトークンは、この確認を通ってしまいます。
告知は、今回の件を前回の修正が不十分だったもの(incomplete fix)としています。
奪われたトークンでできること
告知と、KEDAが配る2.20.2の導入用のファイル(マニフェスト)で、オペレーターの権限を確かめました。主なものは次のとおりです。
オペレーターの権限
何が困るか(告知の説明)
すべての名前空間のSecret(パスワードや鍵の置き場所)を読む
もっと強い権限のトークンを探し出せる
クラスター全体でJob(一回きりの処理)を作る・消す
守りの緩い名前空間で処理を動かし、サーバーのファイルや管理用の設定ファイルに届くおそれがある
どのアプリでも台数を変える
アプリを止めたり増やしたりできる
受け付けの検査の設定(validatingwebhookconfigurations)を書き換える
クラスターに入るものの検査を書き換えたり止めたりできる
APIの振り分けの設定(apiservices)を書き換える
一部のAPIの通り道を乗っ取れる
告知は、実際の環境では「名前空間の管理者からクラスター管理者への権限昇格」に当たると書いています。
GitHubのデータベースのKEDAの告知。対象の版と直した版、CVSS 9.9が並ぶ 出典: GitHub(GitHub Advisory Database) (引用) 誰が狙えるか
告知が挙げる前提の条件は、次の2つです。
自分の名前空間で、TriggerAuthenticationとScaledObjectを作れる。あわせて、Kubernetesに最初からある「edit」のロール(名前空間の中の物を作る・変える権限)を持つ
KEDAが既定の設定で入っている
告知は、複数のチームで分け合うクラスターでは、名前空間の管理者のロールでこれらの権限が渡されていることが多いとしています。報告者は、既定の設定で入れた2.20.0を使い、検証用のクラスターで確かめたと書いています。
Vaultを使っていない会社も対象になります。送り先は、攻撃する側が自分で書くからです。KEDAの移行の手引きも、次のように書いています。
A cluster without legitimate Vault use can still benefit from the fix if untrusted users can create or reference authentication and scaling resources.
出典: KEDA「Migration Guide(Upgrading from KEDA 2.20 to 2.21)」
正規にVaultを使っていないクラスターでも、信頼できない利用者が認証や台数の設定を作れる・参照できるなら、修正が効くという意味です。
Helm(Kubernetesの導入の道具)でKEDAを入れた場合は、rbac.aggregateToDefaultRolesという設定も見ます。trueにすると、KEDAの設定を作る権限が、既定のeditやadminのロールに入ります(Helmの設定の説明)。この値の既定はfalseです。
マニフェストをGitのリポジトリに置き、Argo CDなどの道具で自動で反映している会社もあります。この場合は、リポジトリに書き込める人も「作れる人」に入ります(編集部の補足)。
対象の版と直した版
対象
直した版
KEDA v2(2.20.2以前)
2.21.0
KEDA v1(1.5.0以前)
なし
GitHubのデータベースは、v2の対象を「2.21.0より前」、v1の対象を「1.5.0以前」としています。v1には直した版がありません。前回の修正が入った版(2.17.3、2.18.3、2.19.0以降)を使っていても、今回の件は残ります。
日付を整理します。KEDAは9月23日、自分のリポジトリで告知を出し、2.21.0を公開しました。CVEの番号は10月14日に公開され、GitHubのデータベースへの掲載は10月15日です(いずれも米国時間)。
悪用について、KEDAの告知とリリースノートに記載はありません。米国CISAのKEV(悪用が確認された脆弱性の一覧)には、10月16日版で載っていません。NVD(米国の脆弱性データベース)は10月17日時点で分析の前で、出ているCVSSはKEDAの告知と同じ値です。
2.21.0に上げる前に知っておくこと
2.21.0は、互換性のない変更(breaking change)を3つ含みます。その1つが、この脆弱性の修正です。
KEDA 2.21.0のリリースノート。CVE-2026-77524の修正と上げる前の注意 出典: KEDA(kedacore/keda) (引用) トークンの宛先を必ず決めるようになる
2.21.0では、外に送るトークンに、管理者が決めた宛先(audience)が要るようになりました。手引きは、KubernetesのAPIサーバーが受け付けない宛先を選ぶよう求めています。こうすると、トークンが漏れても、KubernetesのAPIでは受け付けられません。
設定の見直しが要るのは、2つの使い方です。VaultのKubernetes認証と、boundServiceAccountToken(KEDAがトークンを作って渡す認証)です。ふつうのVaultのトークン、APIキー、OAuthなどを使う場合は、この変更での見直しは要らないと手引きは書いています。
手引きによると、設定が足りないと、オペレーターは動いていても一部の自動の増減だけが止まります。そのため、Helmの完了やDeploymentの状態だけでは判断しません。ScaledObjectの状態、イベント、オペレーターのログも見るよう勧めています。
古い動きに戻す設定は一時しのぎ
すぐに移せない連携のために、古い動きに戻すlegacyモードがあります。手引きは、これをクラスター全体に効く安全でない逃げ道と呼び、脆弱な状態のままになると書いています。
2.21.0のマニフェスト(keda-2.21.0.yaml)には、KEDAの設定を作る権限を、既定のeditとadminのロールに足す定義が入っています。2.20.2のマニフェストにはありません。legacyモードのままにすると、作れる人が増えたうえで、今回の穴が開いたままになります(編集部の整理)。
Vaultの送り先を絞る設定もある
2.21.0には、Vaultの送り先を、許可した宛先だけに絞る設定(outboundFilter)も入りました。既定はoffで、使うかどうかは任意です。手引きは、まずwarnで今の送り先を洗い出し、確かめてからenforceにするよう勧めています。
ほかの2つの互換性のない変更は、Temporalの古い設定の削除と、Azure Pipelinesの数え方の変更です。使っている会社は、移行の手引きで確かめます。HelmのチャートとKEDA本体は、同じ版にそろえて上げるよう手引きは求めています。
影響する会社・しない会社
影響する: KEDAの2.20.2以前を、自社のKubernetesのクラスターで使っている会社。クラウドのKubernetes(EKS、GKE、AKSなど)に自分で入れた場合も含みます
影響する: とくに急ぐのは、1つのクラスターを複数のチームや部署、取引先で分け、名前空間の管理を任せている会社です
影響する: Vaultを使っていない会社も、上の条件に当たれば対象です
影響しない: 2.21.0以降に上げ、legacyモードを使っていない会社
影響しない: KEDAを使っていない会社
確認が要る: AKSのKEDAアドオンなど、クラウドの事業者が管理する形で使っている会社。AKSでは、入るKEDAの版はクラスターのKubernetesの版で決まります(Microsoftの文書)。この脆弱性への対応は、事業者の案内で確かめます
確認が要る: 開発会社や委託先がクラスターを運用している会社。版と権限の渡し方は、運用している側に聞きます
情シスが今日やること
KEDAを使っているかと、版を確かめます。 Kubernetesを運用する担当者や委託先に聞きます。KEDAの前回の告知は、kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}" でオペレーターの版を見る方法を載せています(名前空間がkedaの場合。AKSのアドオンはkube-system)。TriggerAuthenticationとScaledObjectを作れる人を洗い出します。 名前空間の管理者のロールに加え、Helmの設定(rbac.aggregateToDefaultRoles)と、GitOpsのリポジトリに書ける人も見ます。上げるまでは、作る・変える権限を信頼できる人だけにします。 今回の告知に回避策の節はありません。前回の告知(同じ処理が対象)では、KEDAはTriggerAuthenticationの権限を絞ることを「唯一の有効な回避策」としていました。2.21.0へ上げる計画を立てます。 見直しが要る設定(VaultのKubernetes認証とboundServiceAccountToken)を洗い出します。検証用の環境で試してから、本番に入れます。上げる日と担当者を決め、名前空間を任せているチームにも知らせます。今ある設定と、上げた後の動きを見ます。 今あるTriggerAuthenticationを開き、Vaultの送り先に知らない宛先がないかを確かめます(編集部の補足)。項目の名前はhashiCorpVault.addressです。上げた後は、ScaledObjectの状態とイベント、legacyの警告がログに出ていないかを見ます。
Kubernetesの管理の基盤の権限昇格は、Rancherに権限昇格の脆弱性 更新を確認 でも扱っています。
