Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-26T14:16:41.903Z",
  "pubdate": "2026-09-26T14:16:41.903Z",
  "executiveSummary": "This vulnerability is an Improper Access Control flaw within the capgo.app OTA update platform. The issue resides in the transfer_app() database function, which fails to perform a cascading deletion or revalidation of record entries in the channel_permission_overrides table during an organization-to-organization app migration.\nThe vulnerability allows an authenticated user, who previously held channel-level permissions within a source organization, to retain these privileges after the associated application has been transferred to a destination organization. By maintaining these 'stale' permissions, an attacker can manipulate channels belonging to a new, unauthorized organization despite having no valid membership or RBAC binding in that context.\nThe impact is significant: an attacker can leverage their existing authenticated JWT to interact with the PostgREST API to modify channel configurations. This allows the redirection of production applications to malicious or unauthorized bundles, facilitating supply chain attacks via the /updates endpoint. The vulnerability affects all versions up to the current release, as existing fixes for permission creation do not remediate the state of already orphaned records.",
  "technicalDetails": "The root cause of this vulnerability is a state-inconsistency flaw in the database schema and logic governing app transfers. Specifically, the transfer_app() function performs a relational copy of an application, its associated channels, versions, and metadata to a new organization scope without sanitizing the channel_permission_overrides table.\nWhen an application is moved, the channel_permission_overrides table retains rows mapped to the original, now-irrelevant, organization membership. Because the PostgREST API relies on these orphaned rows to authorize requests, an attacker who previously held an override for a specific channel ID maintains access to that same channel ID even after the object's parent organization changes. This bypasses the intended multi-tenancy isolation model.\nThe exploitation flow proceeds as follows: 1) The attacker is legitimately granted channel-level overrides within an application in Organization A. 2) The application is transferred to Organization B. 3) The attacker retains their authenticated JWT, which the API uses to query channel_permission_overrides. 4) Since the orphaned record remains in the database, the API validates the attacker's request against the channel in Organization B. 5) The attacker issues a request to the PostgREST API to update the channel's target bundle identifier. 6) The /updates endpoint serves the attacker-controlled bundle to end-user devices, effectively compromising the integrity of the OTA update pipeline.\nThis vulnerability requires the attacker to have a valid, authenticated JWT from the platform, which is easily obtainable via standard user registration. No further elevated privileges are required, as the vulnerability resides in the backend's failure to revalidate authorization at the time of the request against the current organizational context. This is a logic error that bypasses standard RBAC, as the system incorrectly assumes that the existence of a row in channel_permission_overrides implies current authorized access to the associated resource."
}