CVE-2026-61850
Kargo: Privilege escalation via Project RBAC management in the Kargo API
What happened?
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.
Affected software and versions
| Software | Version information | Fixed version |
|---|---|---|
| kargoakuity | affected: >= 0.6.0, < 1.8.14; affected: >= 1.9.0-rc.1, < 1.9.9; affected: >= 1.10.0-rc.1, < 1.10.8 | See vendor advisory |
Version information comes from the source record and can include unaffected products and exceptions. Distribution packages may contain backported fixes: an older upstream version alone does not prove a server is affected.
Is it being exploited?
This CVE was not listed in the CISA catalogue at our last retrieval. This does not establish that exploitation is absent.
How to respond
- Confirm the product, installed package version, and any configuration requirements in the vendor advisory.
- Follow the vendor’s remediation or workaround guidance in the references below. Structured fixed-version data is unavailable here; the publisher’s description may include a fix or workaround.
- Restart affected services if required, then verify the running version. Known exploitation may warrant investigation as well as patching.
Sources and remediation references
- https://www.cve.org/CVERecord?id=CVE-2026-61850
- https://github.com/akuity/kargo/security/advisories/GHSA-wp4p-hr79-q4g8
- https://github.com/akuity/kargo/commit/19639678811b486bddb014dabb25397771f3941e
- https://github.com/akuity/kargo/commit/50d29c10153965114f903645c83eadbe7bf58d3f
- https://github.com/akuity/kargo/commit/5ab7c4216a4151f55ea8ef9ff3b9f884dd322578
- https://github.com/akuity/kargo/commit/72fadd3600b35e6dce67042eb686720a48b45fa3
- https://github.com/akuity/kargo/releases/tag/v1.10.8
- https://github.com/akuity/kargo/releases/tag/v1.11.0-rc.1
- https://github.com/akuity/kargo/releases/tag/v1.8.14
- https://github.com/akuity/kargo/releases/tag/v1.9.9