Capgo Scoped API Key Bypass: Cross-org Destructive Actions via RBAC Inheritance

Vulnerability Overview Title: Scoped API key can perform cross-org destructive actions by inheriting owner-user permissions Description: A verification bypass vulnerability was discovered in the organization management API. An API key explicitly scoped to Org B can still perform destructive actions against Org A if the key's owner has sufficient permissions in both organizations. Root Cause: Route-level authorization accepts the API key owner's user permissions and then enforces the API key's scope. The downstream data layer blocks some writes with Row-Level Security (RLS) but fails to block side effects occurring before or after the write, which are driven by service-role privileges. Severity: High Affected Endpoints: 1. 2. Vulnerability Category: Broken Access Control Cross-Tenant or Cross-Organization Authorization Bypass Permission Delegation Scope Bypass Impact Analysis Prerequisites: 1. A single Capgo user is an Admin or Super Admin of Org A (the victim organization) and also an Admin or Super Admin of Org B (the attacker-controlled organization). 2. The user creates an API key with a mode and set to . 3. The attacker uses this delegated API key to target Org A. Technical Root Cause: 1. The middleware authenticates the API key and stores the owner user ID. 2. Route-level permission checks trust the owner user rather than the API key's scope. 3. RBAC Organizations: The user principal is checked before the API key principal. 4. Legacy Organizations: Organization-level permission checks ignore the API key scope. Exploitability: Although the final write operation is protected by RLS, the route guard returns success, and privileged side effects still occur through service-role-based operations. Verified Impact: 1. Cross-Organization Destructive Deletion of Organization Images: A write API key restricted only to Org B can delete organization images in Org A. 2. Cross-Organization RBAC Permission Stripping: A write API key restricted only to Org B can delete user memberships and role bindings in Org A. Remediation Short-term Hardening: 1. For requests with API key authentication, enforce and before applying any user-based permissions. 2. Add explicit organization scope checks, such as within : Detailed Steps: Validate the API key's scope at the middleware layer. Ensure the API key's scope is correctly applied in route-level permission checks. Ensure the API key's scope is correctly checked and applied in both RBAC and Legacy Organizations. Code Example: Expected Behavior: Any request using an API key scoped to Org B, when targeting Org A, should be rejected before any side effects occur. The endpoint should return an authorization error, such as 401 or 403. Service-role-based cleanup or storage deletion should not occur. Actual Behavior: Route-level authorization succeeds due to owner user permission leakage. The endpoint returns 200 ( ). Cross-organization destructive side effects occur despite the key being out of scope. Why This Matters for Multi-Tenant Security: This issue undermines the core trust model of delegated API keys. The purpose of is to allow users to create more restricted credentials for improved security. In this case, the restriction is not consistently enforced. Restricted keys are not a reliable isolation boundary. Organizations may be affected by credentials never intended to access them. Delegated automation or integrations can become attack paths across tenants. Additional Observations: appears to be intentionally protected by JWT authentication plus and currently does not seem like a strong candidate for reporting. appears to have explicit scope and policy checks, which were missing in the vulnerable organization deletion flow. This makes the organization deletion path the clearest vulnerable branch.

Goal Reached Thanks to every supporter — we hit 100%!

Capgo Scoped API Key Bypass: Cross-org Destructive Actions via RBAC Inheritance

More from this source