Capgo (capgo.app backend, versions ≤ 12.261.0) improperly restricts which roles the apikey_manager…

Why it is Yellow

• CVSS 6.5 medium

References

• https://github.com/Cap-go/capgo.app/security/advisories/GHSA-2x4j-p4pr-fvp8
• https://www.vulncheck.com/advisories/capgo-apikey-manager-role-privilege-escalation-via-incomplete-role-deny-list
• https://github.com/Cap-go/capgo.app/security/advisories/GHSA-2x4j-p4pr-fvp8

Original description

Capgo (capgo.app backend, versions ≤ 12.261.0) improperly restricts which roles the apikey_manager organization role may bind to newly created API keys. When an authenticated user holding only apikey_manager (permissions org.manage_apikeys and org.read) calls POST /apikey with a JWT session, the only checks applied are the org.manage_apikeys permission, a fixed deny-list of assignable role names (APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES in public/apikey/scope.ts), and a priority-rank comparison in createRoleBindingForPrincipal (private/role_bindings.ts). No check verifies that the caller actually holds the permissions conferred by the role being assigned. Because the deny-list omits the deploy roles app_developer, app_uploader, channel_developer and channel_uploader, and apikey_manager is seeded with priority_rank 78 — higher than those roles' ranks (68, 66, 58, 57) — the rank check also passes. As a result, an apikey_manager who cannot upload bundles or promote channels can mint an API key bound to a deploy role and use it to push arbitrary OTA JavaScript updates to all end users of the organization's apps. As of the advisory publication no patched version was available.