CVE-2026-56231 Capgo BOLA Vulnerability: Cross-Tenant Build Sabotage

Technical summary

The vulnerability is a broken object-level authorization (BOLA) flaw in the POST /build/start/:jobId and POST /build/cancel/:jobId endpoints. The application authorizes requests by checking only the app_id parameter supplied in the request body, but fails to validate that the jobId referenced in the URL actually belongs to that app_id or exists within the same tenant/organization. An authenticated attacker with the app.build_native permission can craft requests specifying a valid jobId from a victim organization while supplying their own app_id, causing the backend to execute privileged builder commands (issued via the server's stored builder API key) against the wrong tenant's build infrastructure.

Business impact

Organizations using Capgo for mobile app builds face three material risks: (1) Operational disruption—attackers can cancel critical builds in progress, delaying production releases; (2) Resource abuse—unauthorized build jobs consume cloud compute and storage, inflating operational costs; (3) Reputational and competitive harm—malicious actors could sabotage competitor builds or sabotage their own organization's builds to frame rivals. Multi-tenant SaaS providers are especially vulnerable because a single compromised user account with build permissions can impact multiple customer organizations.

Affected systems

Capgo before version 12.128.2 is affected. The vulnerability requires the attacker to possess the app.build_native permission within their own tenant, meaning internal developers or third-party build users with that role are the primary threat vectors. Cross-tenant impact means all Capgo customers sharing the same instance are at risk if any one of them has a user with build permissions who is compromised or malicious.

Exploitability

Exploitability is relatively straightforward for insiders. The attack requires authentication (a valid Capgo user account with app.build_native permission) and knowledge of a target jobId, but jobIds may be enumerable or discoverable through standard reconnaissance. No user interaction is required, and the network attack surface is direct—no client-side bypasses or complex chaining needed. The barrier to exploitation is low-to-moderate for any authenticated user willing to probe other tenants' job identifiers.

Remediation

Upgrade to Capgo version 12.128.2 or later. This version implements proper object-level authorization checks ensuring that the jobId in the URL is validated to belong to the app_id and tenant context of the authenticated user before executing any builder commands. Organizations unable to upgrade immediately should restrict the app.build_native permission to trusted administrators and monitor build logs for unexpected job cancellations or starts from unusual API patterns.

Patch guidance

Apply Capgo 12.128.2 or later as soon as feasible. This is a critical cross-tenant isolation issue and should be prioritized ahead of most other updates. Verify the patch release notes confirm the authorization checks have been implemented for both /build/start and /build/cancel endpoints. If you maintain a staging environment, test the upgrade there first to ensure no build workflows are disrupted, then promote to production. Post-patch, review your user permissions and consider auditing recent build activity for any anomalies.

Detection guidance

Examine Capgo API logs and audit trails for the following indicators: (1) POST requests to /build/start or /build/cancel with jobIds that do not match the requesting user's organization or app; (2) Rapid or sequential build cancellations across multiple distinct apps or tenants; (3) Build job activity from users or service accounts that do not typically interact with those apps; (4) Unusual patterns in the app_id parameter in request bodies that differ from the authenticated user's expected scope. If available, correlate build log anomalies with user login times and IP addresses to identify potential account compromise.

Why prioritize this

This merits immediate attention due to its cross-tenant isolation breach, the authenticated-but-widespread attack surface (any user with build permissions poses a risk), and the tangible operational and financial impact. Unlike many BOLA flaws that affect a single user's personal data, this one directly compromises infrastructure availability and cost control across multiple customers. Combined with the HIGH CVSS score and the relative simplicity of exploitation, it should be treated as a critical priority.

Risk score, explained

The CVSS 3.1 score of 7.6 (HIGH) reflects: Attack Vector Network (broad exposure via standard API endpoints), Attack Complexity Low (no special conditions required), Privileges Required (authenticated users only, a common but significant gate), Scope Unchanged (impact confined to one security domain), and impact on Confidentiality (partial—some app metadata may be exposed), Integrity (partial—job state is modified), and Availability (high—builds can be denied). The cross-tenant nature and lack of CVSS scope escalation may keep the numeric score from 'CRITICAL', but the real-world harm of infrastructure sabotage and multi-customer impact elevates the practical risk significantly.

Frequently asked questions