CVE-2026-100611 in Capgo
Summary
by MITRE • 09/26/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Capgo backend versions 12.261.0 and earlier represents a critical authorization bypass rooted in flawed role assignment logic within the API key management subsystem. This flaw allows an authenticated user possessing only the apikey_manager organization role to escalate their privileges by binding newly created API keys to higher-privilege roles that they do not inherently possess. The core of the issue lies in the insufficient validation performed during the creation of API keys via the POST /apikey endpoint when accessed with a JWT session. While the system correctly verifies that the caller holds the org.manage_apikeys permission, it fails to validate whether the caller actually has the authority or permissions required for the specific role being assigned to the new key. This oversight creates a significant gap in access control enforcement, allowing users with limited administrative capabilities to effectively assume roles reserved for developers and uploaders within the organization.
The technical mechanism of this exploitation relies on two primary failures: an incomplete deny-list and a flawed priority-rank comparison logic. The system utilizes a fixed list named APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES in public/apikey/scope.ts to restrict certain role assignments, but this list omits critical deploy roles such as app_developer, app_uploader, channel_developer, and channel_uploader. Furthermore, the createRoleBindingForPrincipal function in private/role_bindings.ts employs a priority-rank comparison rather than strict permission inheritance checks. The apikey_manager role is seeded with a priority_rank of 78, which is higher than the ranks assigned to the omitted deploy roles (68 for app_developer, 66 for channel_uploader, 58 for channel_developer, and 57 for app_uploader). Consequently, when an apikey_manager attempts to assign one of these lower-ranked but high-privilege roles to a new API key, both the deny-list check passes due to omission, and the rank-based validation succeeds because the caller's role has a higher numerical priority. This combination effectively bypasses intended access controls without requiring any additional authentication or privilege escalation steps beyond what is normally available to an apikey_manager.
The operational impact of this vulnerability is severe, particularly in environments where over-the-air (OTA) JavaScript updates are used for application distribution. By minting an API key bound to a deploy role such as app_uploader or channel_uploader, an attacker can push arbitrary OTA JavaScript code directly to all end users within the organization's applications. This capability effectively grants the attacker full control over the client-side execution environment of the affected apps, enabling potential data exfiltration, session hijacking, defacement, or installation of malicious functionality under the guise of legitimate application updates. Since these updates are delivered directly to user devices without requiring app store re-submission or review, the attack vector is both stealthy and immediate. The lack of verification that the caller holds the permissions conferred by the assigned role means that any individual with apikey_manager access can compromise the integrity and security posture of the entire organization's mobile ecosystem.
From a classification perspective, this vulnerability aligns with CWE-269: Improper Privilege Management, specifically regarding the failure to enforce proper authorization checks when assigning roles or privileges. It also relates closely to CWE-862: Missing Authorization, as the system fails to verify that the actor has the necessary permissions for the action being performed (assigning a high-privilege role). In terms of offensive security frameworks, this behavior is consistent with MITRE ATT&CK technique T1078.004: Valid Accounts - Cloud Accounts, where an attacker uses legitimate credentials and excessive privileges to maintain access or escalate control within a cloud-based service environment. The exploitation does not require remote code execution vulnerabilities in the traditional sense but rather abuses the logical flaws in identity and access management policies.
Mitigation strategies must focus on correcting the role assignment logic and hardening the API key generation process. Immediate remediation should involve updating the deny-list to explicitly include all deploy-related roles, ensuring that apikey_manager cannot bind keys to app_developer, app_uploader, channel_developer, or channel_uploader regardless of priority ranks. More robustly, the system must implement a strict permission inheritance check where the caller is verified to hold at least one of the permissions associated with the target role before allowing the binding. This ensures that only users who genuinely possess developer or uploader privileges can create API keys for those purposes. Additionally, implementing principle of least privilege by reducing the priority_rank of apikey_manager below that of deploy roles would provide a secondary layer of defense, although explicit permission validation remains the primary requirement for secure access control. Organizations using Capgo should monitor for any unauthorized OTA updates and consider rotating existing API keys until patched versions are available from the vendor.