Kargoで権限昇格の脆弱性、修正版を公開
KargoのプロジェクトRBAC管理APIに、委任された権限を超えて自分の権限を引き上げられる脆弱性が見つかりました。管理者がカスタムロールを作って運用している環境は、1.8.14・1.9.9・1.10.8の修正版へ更新してください。
急ぎ度: 早めに
CVSS v4は9.3で重大に分類され修正版も出ていますが、悪用にはRBAC管理を委任されたアカウントが必要で、標準ロールでは起きないため、至急ではなく早めの更新が妥当です。
関係があるか
Kargoで複数のProjectを運用し、管理者以外にRolesやServiceAccountsの編集権限を持たせている組織が対象です。標準ロールだけで運用していれば、この脆弱性は悪用されません。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Kargo（akuity/kargo）1.8系 | 0.6.0以降、1.8.14より前 | 1.8.14 |
| Kargo（akuity/kargo）1.9系 | 1.9.9より前 | 1.9.9 |
| Kargo（akuity/kargo）1.10系 | 1.10.8より前 | 1.10.8 |
確かめ方
- 1Kargo APIサーバーの版を確認します。CLIの
kargo versionで、サーバー側の版が表示されます。 - 2管理者が作ったカスタムロールを洗い出し、RolesまたはServiceAccountsの編集権限が含まれていないかをProjectごとに見ます。含まれていなければ、この脆弱性の悪用条件は満たされません。
- 3含まれている場合は、そのロールを割り当てられているアカウントの一覧を作り、本当に必要な人だけかを確かめます。
- 41.11系を使っている場合は、ベンダーのセキュリティアドバイザリで影響の有無を確認します。
何が起きたか
KargoのProject単位のRBAC管理APIで、自分が持っていない権限を他人や自分自身に付けられる脆弱性が見つかりました。Projectの管理者に近い権限へ昇格でき、Secretsや外部サービスの認証情報を読まれ、リソースを書き換えられたり削除されたりするおそれがあります。
KargoのRoleは、ServiceAccount、Role、RoleBindingの3つで、Projectのnamespace内に作られます。原因は権限の確認が粗いことです。APIサーバーは変更を書き込むとき、強い権限を持つ自身の認証情報を使います。ところが確認するのは「Rolesや ServiceAccounts を編集してよいか」という種類単位の可否だけで、付与しようとする個々の権限が操作者本人の持つ範囲に収まるかは見ていませんでした。
欠陥は2通りあります。Rolesの編集権限を持つ人は、自分にない権限を含むルールを作成、置換、追加できます。RoleのServiceAccountを編集できる人は、自分のアカウントを含む任意のIDを、より強いRoleに結び付けられます。
CWEは権限の不適切な管理を示すCWE-269に分類されています。公表は2026年10月30日です。
攻撃の流れ
-
1
委任された権限
管理者作成のカスタムロールにより、Project内のRolesやServiceAccountsを編集できるアカウントを使います。
-
2
権限の上乗せ
自分にない権限を含むルールを作るか、自分のIDをより強いRoleに結び付けます。
-
3
管理者相当に昇格
APIサーバーの強い認証情報で書き込まれるため、変更がそのまま通ります。
-
4
情報の取得と改変
Project Secretsや認証情報の読み取り、Project内リソースの変更や削除に至ります。
どう悪用されるか
悪用にはKargoの認証済みアカウントが必要で、そのアカウントがProjectのRolesまたはServiceAccountsを編集できる権限を持っていなければなりません。標準の非管理者ロールにはこの操作が許されていないため、管理者が作ったカスタムロールでその権限を渡し、そのロールが割り当てられたアカウントを攻撃者が使える場合に限られます。ネットワーク経由で操作でき、利用者の操作は要りません。
昇格の範囲は、攻撃者がすでにRBAC管理を委任されているProjectの中です。クラスター全体や別のProjectへのアクセスは、この脆弱性だけでは得られません。
被害はProject内で大きくなります。Projectの管理者相当の権限を得られ、Project Secretsや認証情報が読まれ、リソースが変更や削除されるおそれがあります。盗まれたGit、コンテナレジストリ、Helmレジストリの認証情報は外部のシステムにも使えるため、機密性と完全性への影響はKargoの外にも及びえます。
今すぐやること
-
1
修正版に更新する
使っている系統に合わせて、1.8.14、1.9.9、1.10.8のいずれかに更新します。1.11系を使っている場合は、ベンダーのアドバイザリとリリースノートで対応状況を確認します。
kargo version -
2
カスタムロールの権限を見直す
RolesやServiceAccountsの編集権限を含むカスタムロールを洗い出します。必要のない人からは外し、更新までの間も付与先を最小限にします。
-
3
不審な権限変更がないか調べる
各ProjectのRole、RoleBinding、ServiceAccountの最近の変更を確認します。管理者が意図していない権限追加や、強いRoleへの結び付けがないかを見ます。
-
4
疑わしければ認証情報を入れ替える
権限が不審に変わっていたProjectでは、Project Secretsに入っているGit、コンテナレジストリ、Helmレジストリの認証情報を失効させて再発行します。外部システム側のアクセスログも確認します。
すぐ更新できないとき
すぐに更新できない場合は、RolesやServiceAccountsの編集権限を含むカスタムロールを一時的に外し、Kargoの管理者だけが権限を変更できる状態にします。標準の非管理者ロールではこの操作が許されていないため、この状態なら悪用の条件は成り立ちません。
背景
Kargoは、Akuityが開発しているソフトウェア成果物のプロモーションを管理し自動化するツールです。コンテナイメージやマニフェストを、開発から本番までのステージに沿って進める役目を担います。そのためProjectごとに、Gitやコンテナレジストリ、Helmレジストリへの認証情報を預かります。Project内で強い権限を得られると、Kargoの中だけでなく、成果物の供給元にまで影響が及びます。
KubernetesのRBACには、自分が持たない権限を含むRoleを作れないようにする仕組みが標準で備わっています。今回の脆弱性は、KargoのAPIサーバーが利用者の代わりに強い権限で書き込むため、その防止が働かなかったことが原因です。権限を委任する機能を持つ製品では、委任された側の権限で書き込めるか、付与内容が委任された範囲に収まるかを、個別の権限ごとに確かめる設計が必要になります。
よくある質問
Q.標準のロールだけで運用していても更新は必要ですか。
Q.SaaSやクラウドで提供されているKargoも対象ですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Kargo manages and automates the promotion of software artifacts. From 0.6.0 until 1.8.14, 1.9.9, and 1.10.8, two authorization flaws in the project-scoped RBAC API let an authenticated user with delegated permission to manage a Project's Roles or ServiceAccounts confer permissions exceeding the user's own. A user authorized to edit Roles can create, replace, or add rules granting permissions not held by the user; a user authorized to edit a Role's ServiceAccount can bind an identity, including the user's own, to a more powerful Role. A Kargo Role comprises a ServiceAccount, Role, and RoleBinding in the Project namespace. Changes are written using the API server's broadly privileged credentials after only a coarse resource-kind edit check, rather than checking each permission being conferred. This permits escalation to Project-administrator access, disclosure of Project Secrets and credentials, and modification or deletion of Project resources. Stolen Git, container-registry, or Helm-registry credentials can extend confidentiality and integrity impacts to those external systems. Escalation remains limited to Projects where the attacker already has RBAC-management delegation and does not itself grant cluster-wide or cross-Project access. Default non-administrator roles do not permit these operations; exploitation requires an administrator-created custom role granting the relevant permissions and control of an account assigned that role. This issue is fixed in vers…
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- patch github.com
- patch github.com
- patch github.com
- patch github.com
- web github.com
- web github.com
- web github.com
- web github.com