Skip to main content
← All vulnerabilities
CVE-2026-61850

Kargo: Privilege escalation via Project RBAC management in the Kargo API

Affects Kargo 0.6.0 up to 1.8.14, 1.9.0-rc.1 up to 1.9.9, and 1.10.0-rc.1 up to 1.10.8 where a custom role can edit Project Roles or ServiceAccounts. Fixed in 1.8.14, 1.9.9, and 1.10.8.

Published
Last modified
published
Not listed in CISA KEV
Specific setups only
Fix
Fixed in 1.8.14, 1.9.9, 1.10.8
None on Exploit-DB, Metasploit or GitHub
On X
View the cve.now post

Summary

Kargo, an open-source tool for automating software artifact promotion, is affected, specifically its project-scoped RBAC API. An authenticated user who has been delegated permission to manage a project's roles or service accounts can gain more access than they were granted, potentially reaching project-administrator level and exposing project secrets, credentials, or project resources.

Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.

Read the original description

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 versions 1.8.14, 1.9.9, and 1.10.8.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. Posted on X by cve.now

Affected versions

  • akuity kargo

    From 0.6.0 · fixed in 1.8.14; From 1.9.0-rc.1 · fixed in 1.9.9; From 1.10.0-rc.1 · fixed in 1.10.8

References 9

GitHub · akuity/kargo

FAQ

Questions about CVE-2026-61850

What does this mean?

An authenticated user who can manage a Project's Roles or ServiceAccounts could grant themselves permissions they did not already hold. This lets them reach the Kargo API server's permissions within the Project namespace, including reading Project Secrets and credentials and obtaining Project-administrator privileges.Source: github.com

Am I affected, and how do I check?

Versions 0.6.0 up to 1.8.14, 1.9.0-rc.1 up to 1.9.9, and 1.10.0-rc.1 up to 1.10.8 are affected. The setup must include a custom role created by an administrator that grants permission to edit Roles or ServiceAccounts in the Project; to check, review the Kargo version and the custom roles defined for each Project.Source: github.com

What should I do about it?

Upgrade to 1.8.14, 1.9.9, or 1.10.8, whichever matches the release line in use. Until then, restrict Project-scoped permissions to manage Roles and ServiceAccounts to users who are already intended to have full administrative access to the Project.Source: github.com

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data