CVE-2026-100613 in Capgo.app
Summary
by MITRE • 09/26/2026
capgo.app is an over-the-air (OTA) update platform for Capacitor apps. In all versions up to and including the current release (no patch available at time of publication), the `transfer_app()` database function transfers an app, its channels, versions and related records to a destination organization without deleting or revalidating existing rows in `channel_permission_overrides`. As a result, a user who legitimately held a channel permission override while a member of the source organization retains that override after the transfer, even though they have no membership and no RBAC binding in the destination organization. Using their own authenticated JWT against the PostgREST API, such a former member can modify the destination-owned channel to point at a different bundle, causing the /updates endpoint to serve an attacker-selected application version to devices. The previously proposed fix for GHSA-626c-p6fq-3whq (PR #3093), which validates organization membership when an override is created or updated, does not remove overrides that became stale as a result of an app transfer.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in capgo.app, specifically within its over-the-air update platform for Capacitor applications, represents a critical authorization bypass rooted in improper state management during organizational data migration. The core technical flaw resides in the `transfer_app()` database function, which is responsible for moving an application along with its associated channels and versions from one organization to another. While this process correctly transfers the primary assets, it fails to perform necessary cleanup of related records in the `channel_permission_overrides` table. Consequently, when a user who possessed specific channel permission overrides as a member of the source organization is part of such a transfer, those override entries are copied or retained without being invalidated or revalidated against the destination organization's identity and access management system. This results in orphaned permissions where former members retain administrative-level control over channels that now belong to a different entity, effectively creating a persistent backdoor into the new organizational context.
The operational impact of this flaw is severe, allowing for potential supply chain attacks through malicious OTA updates. An attacker who was previously authorized within the source organization can leverage their existing authenticated JSON Web Token against the PostgREST API to interact with the destination-owned channels. Because the system does not verify current membership status or Role-Based Access Control bindings in the target environment during these specific override interactions, the attacker retains the ability to modify channel configurations. Specifically, they can redirect a channel to point at a different application bundle hosted by an adversary-controlled server. This manipulation causes the /updates endpoint to serve unauthorized and potentially malicious application versions to end-user devices that are configured to receive updates from that channel. Such actions compromise the integrity of the software distribution pipeline, allowing for code injection, data exfiltration, or device compromise on a large scale without requiring new authentication credentials or exploiting additional vulnerabilities in the token validation logic.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site, as it involves unauthorized modification of configuration settings leading to redirection to untrusted content. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1505.003 Web Shell: Custom Command and Scripting Interpreter if the bundle contains executable scripts, or more broadly to Supply Chain Compromise (T1195) by manipulating the update mechanism. The flaw is exacerbated by the fact that a previously proposed fix for related issues, such as GHSA-626c-p6fq-3whq via PR #3093, only addressed permission validation at the time of creation or update but failed to account for stale permissions resulting from structural changes like app transfers. This oversight highlights a common pitfall in stateful systems where lateral movement across organizational boundaries is not fully sanitized.
To mitigate this vulnerability, immediate remediation must focus on ensuring that any data migration operation includes comprehensive cleanup of dependent permission records. The `transfer_app()` function should be updated to explicitly delete or invalidate all entries in the `channel_permission_overrides` table associated with users who do not have corresponding memberships in the destination organization. Additionally, implementing a strict validation layer at the API level is essential; every request modifying channel configurations must verify that the authenticated user holds valid RBAC bindings within the specific context of the target resource's owner organization. This defense-in-depth approach ensures that even if database records are erroneously retained, the application logic will reject unauthorized actions based on current organizational membership status rather than relying solely on historical permission states. Regular audits of cross-organizational data transfers and automated testing for orphaned permissions can further reduce the risk of similar authorization bypasses in future releases.