Kargo: Privilege escalation via Project RBAC management in the Kargo API
Impact
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…
Source excerpt · GitHub_MDefault 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.
Affected packages
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
akuity · GitHub_M
kargo
3 ranges
akuity · GitHub_M
kargo
Compare with this publisher’s ranges. This does not inspect your installation.
affected
>= 0.6.0, < 1.8.14
>= 1.9.0-rc.1, < 1.9.9
>= 1.10.0-rc.1, < 1.10.8
Other versions: unknown
Original source 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.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-61850View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 1
Assigning organization
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.