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.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 1.8.14, 1.9.9, 1.10.8
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
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
- CVE published
- First seen by cve.now
- 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
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