Kargo EUVD-2026-114371

Exploitation requires an authenticated Kargo user who holds a Project-scoped, administrator-created CUSTOM role granting permission to edit that Project's Roles or ServiceAccounts, plus control of an account assigned that role - the two Kargo API operations abused are editing a Role's rules and binding an identity to a Role's ServiceAccount. Default non-administrator roles shipped with Kargo do NOT grant these permissions, so an installation that has not defined such a custom role is not affected. Limiting factors per the vendor: authentication to the Kargo API server is mandatory (PR:H), the delegated RBAC-management permission is normally given only to Project admins, no user interaction is needed, and escalation is bounded to Projects where the attacker already has RBAC-management delegation - it does not by itself grant cluster-wide or cross-Project access. The only complete fix is updating to 1.8.14, 1.9.9 or 1.10.8; the stated workaround is to not delegate Role/ServiceAccount management to users who should not already hold the Project's other permissions (e.g., Secret access).

The vuln.today decision label is act_now and the vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L, 9.3) reflects total loss of confidentiality, integrity and availability within a Project plus spillover to external systems - so once the preconditions are met, impact is severe and organizations should apply the fixes without delay. However, the signals are not uniformly alarming: there is no CISA KEV listing, no EPSS score was provided, the vendor explicitly reports 'No known exploitation in the wild', and the only public artifacts are the GHSA advisory and the patch commits - no public exploit code. The CVSS AT:N ('default installations affected') describes only that no race/timing condition is needed; it does NOT mean the flaw is reachable out of the box, because the attacker must still hold an administrator-created custom role granting Role/ServiceAccount edit rights. The vendor itself notes CVSS overweights this case because it under-emphasizes the PR:H barrier. Net assessment: this is a high-impact but precondition-gated privilege-escalation issue - a genuine priority to patch per the act_now decision, but realistic exploitation requires an uncommon custom-role configuration plus compromise of an already fairly privileged account, so it is closer to targeted/insider risk than mass opportunistic exploitation.

An attacker who has compromised an authenticated Kargo account holding an admin-created custom Project role with permission to edit Roles or ServiceAccounts issues an ordinary API request that adds RBAC rules to a Role (or binds their own identity to a more powerful Role). Because the API server writes the change with its own broadly privileged credentials after only a coarse resource-kind check, the attacker escalates to Project-administrator, reads all Project Secrets, and can tamper with Project resources. No public exploit code is identified at time of analysis, and the vendor reports no known exploitation in the wild.