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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T14:16:41.610Z",
  "pubdate": "2026-09-26T14:16:41.610Z",
  "executiveSummary": "Capgo (versions ≤ 12.261.0) contains a critical authorization bypass vulnerability that allows an authenticated user with the apikey_manager role to escalate their privileges. By exploiting improper validation logic during API key creation, an attacker can mint keys bound to roles with higher functional permissions, such as deployment and bundle management roles. The vulnerability stems from insufficient verification of whether the caller possesses the permissions they are assigning to the new API key, combined with an inadequate deny-list and flawed priority-rank comparisons. An attacker leveraging this vulnerability can bypass organizational restrictions to push malicious or unauthorized OTA JavaScript updates to end-user applications. This poses a significant supply chain risk, as it grants unauthorized users the ability to execute arbitrary code within the context of the organization's mobile applications. Exploitation requires valid authentication as an apikey_manager but does not require additional complex preconditions, as the system fails to enforce the principle of least privilege during the key generation flow.",
  "technicalDetails": "The vulnerability resides in the API key creation process within the Capgo backend, specifically during the handling of the POST /apikey endpoint. The root cause is an improper authorization check that fails to validate if the authenticated user has the necessary permissions associated with the role they are assigning to a new API key. When a user with the apikey_manager role (possessing org.manage_apikeys and org.read) invokes the creation process, the system relies on three insufficient checks: a permission check for org.manage_apikeys, a static deny-list (APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES in public/apikey/scope.ts), and a priority-rank comparison in private/role_bindings.ts.\nThe vulnerability is exposed because the existing deny-list omits high-privilege deployment roles such as app_developer, app_uploader, channel_developer, and channel_uploader. Furthermore, the logic in createRoleBindingForPrincipal compares the priority_rank of the caller's role against the target role. The apikey_manager role is seeded with a priority_rank of 78, which is mathematically higher than the ranks assigned to deployment roles (e.g., app_developer at 68, app_uploader at 66, channel_developer at 58, and channel_uploader at 57). Because the rank check passes for these roles and they are absent from the deny-list, the system permits the creation of an API key bound to these elevated roles.\nThe attack flow follows a predictable sequence: First, the attacker authenticates as a user with the apikey_manager role. Second, the attacker submits a POST request to /apikey, specifying a target role that is functionally superior to their own but ranks lower in the priority system. Third, the backend validates the request against the flawed check, confirms the rank priority satisfies the requirements, and proceeds to generate the key. Finally, the attacker uses the newly created API key to perform operations restricted to the deployment roles, such as pushing unauthorized OTA JavaScript updates. This effectively allows an attacker to manipulate the update pipeline, leading to arbitrary code execution across the organization's deployed application base. The vulnerability highlights a failure to verify administrative binding authorization, transforming a management role into a full deployment administrative role."
}