CVE-2026-100616: capgo.app Authentication Bypass via PostgREST customer_id Mutation
capgo.app is an over-the-air update platform for Capacitor apps. In all versions prior to a fix, the row-level security UPDATE policy on the public.orgs table permits an organization admin (a user holding org.updatesettings) to update the entire row, including the internal billing pointer column customerid. The official organization update endpoint (supabase/functions/backend/public/organization/put.ts) allowlists only a small set of editable settings fields and excludes customerid, and the private Stripe billing route separately requires the org.updatebilling permission. By sending an update directly to Supabase PostgREST, an authenticated org admin without org.updatebilling can null or corrupt the organization's Stripe customer pointer, causing plan and billing checks that trust orgs.customerid to fail and moving the organization from a valid paid plan state to unpaid/no-plan behavior. At the time of the advisory no patched version was available.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated organization administrator who has the org.update_settings permission can exploit it. The attacker does not need the separate org.update_billing permission if they send the update directly to Supabase PostgREST.
Are deployments using the official organization update endpoint protected?
The official organization update endpoint allowlists editable settings fields and excludes customer_id. The issue arises because the row-level security UPDATE policy permits direct PostgREST updates to the entire public.orgs row.
What is the impact of a successful exploit?
An attacker can null or corrupt the organization's Stripe customer_id pointer. This can cause plan and billing checks relying on that value to fail, moving a paid organization into unpaid or no-plan behavior.
Is a patch available?
No patched version was available at the time of the advisory.
What mitigation is supported by the advisory data?
Restrict access for users with the org.update_settings permission to trusted administrators, because that permission is sufficient to reach the vulnerable UPDATE policy through PostgREST. The provided information does not identify a configuration-level workaround or a corrected policy.