本文へ移動
English version →
重大 9.9 急ぎ度: 至急

Kyverno 1.19.1の脆弱性で管理者権限に昇格、修正版あり

Kyverno 1.19.1に、自分のnamespaceにPolicyを作れる利用者がクラスター管理者権限まで到達できる脆弱性があります。1.19.1を使う組織は1.19.2へ更新し、不審なwebhook設定がないかも調べてください。

CVE-2026-124440 公開 更新 執筆・監修: 佐々木 航 人が監修しながらAIを活用して執筆
記事のイメージ(生成 AI による画像)
画像は生成 AI で作成したイメージです

急ぎ度: 至急

CVSS v3は9.9、v4は9.4で、低い権限からクラスター管理者権限に到達でき、勧告には再現の手順も載っていますが、修正版1.19.2が出ています。

関係があるか

KubernetesクラスターでKyverno 1.19.1を動かしている組織です。とくに、複数のチームや顧客にnamespace単位でPolicyの作成権限を渡しているマルチテナント環境が当てはまります。

製品影響を受ける版修正版
Kyverno(github.com/kyverno/kyverno) 1.19.1以上、1.19.2未満(実質1.19.1) 1.19.2

確かめ方

  1. 1Kyvernoが動くnamespaceでDeploymentのイメージの版を確認し、1.19.1になっていないか見ます。Helmで入れている場合は、更新後のチャートの版もベンダーの告知で確認してください。
  2. 2kubectl auth can-i で、各テナントのServiceAccountやユーザーがpolicies.kyverno.ioを自分のnamespaceで作成できるかを調べます。作成できる主体がいれば、攻撃の前提を満たします。
  3. 3テナントのnamespaceにあるPolicyのうち、apiCallを使うものを洗い出します。身に覚えのないものは調査の対象です。

何が起きたか

Kyverno 1.19.1には、namespaceを割り当てられた利用者が、自分の範囲を超えて他のnamespaceの情報を読み、最終的にクラスター全体の管理者権限を得られる脆弱性があります。CVSS v3は9.9、CVSS v4は9.4で、深刻度はcriticalです。

原因は、Policyのapi呼び出し機能であるapiCallに対する、namespaceの制限が働かないことです。この制限は1.19.1で追加されましたが、検査する文字列と、実際にKubernetes APIへ送る文字列が別になっています。検査はデコードして整形した写しに対して行い、リクエストは元のパスのまま送ります。デコードに失敗すると、検査は元の文字列に切り替わります。一方、API serverは常にデコードして処理します。urlPathに不正な形式のパーセントエンコードが混ざると、この食い違いで制限をすり抜けます。分類はCWE-441です。

この脆弱性は、1.19.1で修正されたはずの2件(GHSA-c5qq-7g2q-cpqpとGHSA-5qq8-67g6-4h2w)を再び開けてしまいます。前者は他のnamespaceの読み取り、後者はクラスター全体に効くwebhook作成による管理者権限への昇格です。GitHubの勧告は2026年10月23日付で、CVEは2026年11月8日に公開されました。

攻撃の流れ

  1. 1

    Policyを作成

    テナントが自分のnamespaceに、apiCallを含むPolicyを作ります。

  2. 2

    制限をすり抜け

    urlPathに不正な形式のパーセントエンコードを付け、検査と実際の送信先をずらします。

  3. 3

    強い権限で実行

    apiCallがKyvernoのadmission-controllerのServiceAccountとして動き、テナント自身にない権限で呼び出されます。

  4. 4

    他namespaceを読む

    ほかのnamespaceのリソースを読み取ります。

  5. 5

    webhookで昇格

    クラスター全体に効くwebhook設定を作り、クラスター管理者権限に到達します。

公開されている情報をもとにした流れの例です。

どう悪用されるか

攻撃者はネットワーク経由で操作でき、利用者の操作は要りません。前提は、自分のnamespaceでpolicies.kyverno.ioを作成できる権限(namespace単位のテナント権限)だけで、複雑な条件はありません。勧告は、Helmチャート3.9.1の既定値で入れた1.19.1で確認したと書いています。

成功すると、admission-controllerのServiceAccountが読めるリソースを、どのnamespaceからでも読み取れます。構成によってはSecretも含みます。さらに、mutatingwebhookconfigurationsとvalidatingwebhookconfigurationsを作成・更新・削除できます。広い範囲に一致するmutating webhookは、全namespaceの作成・更新リクエストを横取りして書き換えられるため、クラスター管理者権限と同じ意味を持ちます。勧告は、すべてのSecretの読み取り、任意のリソースの改変、ワークロードやコントロールプレーンの削除や妨害まで可能になり、機密性・完全性・可用性を全面的に失うとしています。

今すぐやること

  1. 1

    Kyvernoを1.19.2に更新する

    1.19.1を使っているクラスターは、最優先で1.19.2に更新します。1.19.1より前の版も、1.19.1で修正された2件の対象にあたるため、更新を急いでください。Helmチャートの対応する版は、KyvernoのGitHubの告知で確認します。

    kubectl -n kyverno get deploy -o wide
  2. 2

    不審なwebhook設定を調べる

    1.19.1で動かした期間があるなら、身に覚えのないmutatingおよびvalidatingのwebhook設定がないか確認します。作成者や作成時期が分からないものは、監査ログとあわせて調べます。

    kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations
  3. 3

    テナントのPolicyを点検する

    テナントのnamespaceにあるPolicyのうち、apiCallを使い、urlPathに「%」を含むものを探します。見つかった場合は、作成者と作成日時を確認し、必要なら削除します。

    kubectl get policies.kyverno.io -A
  4. 4

    Policy作成権限を見直す

    テナントにpolicies.kyverno.ioの作成権限が本当に要るかを確認し、不要な権限は外します。更新後もPolicyの作成権限はクラスター全体の安全性に響くため、管理者と限られた運用担当者に絞るのが安全です。

  5. 5

    侵害の疑いがあれば資格情報を入れ替える

    不審なwebhookや、見覚えのないPolicyが見つかったときは、クラスター内のSecretが読まれた前提で、パスワードやトークンの入れ替えを検討します。

すぐ更新できないとき

更新まで時間がかかる場合は、テナントのpolicies.kyverno.ioの作成権限を一時的に外すと、前提条件を断てます。権限の付与はRBACで確認できます。ベンダーが示すほかの回避策は、GitHubのKyvernoの勧告で確認してください。

背景

Kyvernoは、Kubernetesのadmission controllerとして動くポリシーエンジンです。Podやその他のリソースが作られるときに、規則に合うかを検査したり、内容を書き換えたりします。namespace単位のPolicyを使うと、各チームに自分の範囲の規則作成を任せられるため、マルチテナントのクラスターで広く使われます。apiCallは、Policyの判断に使う情報を、Policy自身がKubernetes APIから取ってくる機能です。この呼び出しはテナントではなく、KyvernoのServiceAccountの強い権限で実行されます。

今回の脆弱性は、1.19.1で入れた対策をすり抜けるものです。1.19.1は、他namespaceの読み取りと、クラスター全体に効く書き込みによる昇格という2件を直すために、パスをデコードして整形してから検査する制限を追加しました。ところが、検査した文字列と実際に送る文字列が別だったため、同じ種類の問題が再び開きました。勧告は、特定の入力を除外するだけでは足りず、デコードしたパスを調べるだけでも足りないと述べています。実際に送るパスと同じものを検査する必要があるという設計の話です。

よくある質問

Q.ClusterPolicyだけを使っていて、テナントにPolicyを作らせていなければ影響はありませんか。
A.攻撃にはnamespaceでPolicyを作成できる権限が要るため、その権限を持つ利用者がいなければ、この経路で攻撃される可能性は低くなります。ただし、権限の付与状況は変わりやすく、1.19.1が修正版でないことに変わりはないので、更新はしてください。
Q.PolicyをAuditモードで運用していれば、影響を避けられますか。
A.避けられません。勧告の再現では、validationFailureActionがAuditのPolicyでも、制限の回避が成立しています。運用モードに頼らず、更新と権限の見直しで対応してください。

まだ分かっていないこと

  • PolicyExceptionへの書き込みも同じ回避から起こるとされていますが、勧告ではその再現は個別に行われていません。

この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。

影響パッケージ

パッケージ影響を受ける版 → 修正版
kyvernokyverno
1.19.1 以上 1.19.2 未満→ 1.19.2
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

Kyverno from 1.19.1 before 1.19.2 contains an authorization bypass vulnerability in the apiCall namespace clamp that allows namespace tenants to issue cross-namespace and cluster-scoped API requests by appending malformed percent-escapes to urlPath. Attackers can create namespaced Policies whose apiCall runs as the admission-controller ServiceAccount to read other namespaces' resources and create mutating webhooks, escalating to cluster admin.

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく