Description

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.update_settings) to update the entire row, including the internal billing pointer column customer_id. The official organization update endpoint (supabase/functions/_backend/public/organization/put.ts) allowlists only a small set of editable settings fields and excludes customer_id, and the private Stripe billing route separately requires the org.update_billing permission. By sending an update directly to Supabase PostgREST, an authenticated org admin without org.update_billing can null or corrupt the organization's Stripe customer pointer, causing plan and billing checks that trust orgs.customer_id 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-09-26T14:16:42.333Z",
  "pubdate": "2026-09-26T14:16:42.333Z",
  "executiveSummary": "The capgo.app platform exhibits a critical Insecure Direct Object Reference (IDOR) and improper Row-Level Security (RLS) configuration vulnerability within the public.orgs table. This vulnerability allows an authenticated organization administrator, possessing standard org.update_settings privileges, to bypass intended application logic and directly manipulate sensitive database columns.\nBy interacting directly with the Supabase PostgREST API, an attacker can modify the customer_id field, which is intended to be protected by stricter org.update_billing permissions. Successful exploitation results in the corruption or nullification of the organization's Stripe billing pointer. This state causes the backend systems to incorrectly identify a valid subscription as an unpaid or non-existent plan, effectively forcing a denial-of-service on billing-gated features.\nThe vulnerability highlights a discrepancy between the application-layer security provided by the backend endpoint (supabase/functions/_backend/public/organization/put.ts) and the overly permissive RLS policies enforced at the database level. Attackers require a valid user account with standard administrative rights within an organization to initiate this attack, but no specialized elevated billing permissions are necessary to achieve the unauthorized state modification.",
  "technicalDetails": "The root cause of this vulnerability lies in the misalignment between the application-layer field filtering and the underlying database RLS UPDATE policy on the public.orgs table. While the backend TypeScript function (supabase/functions/_backend/public/organization/put.ts) implements an explicit allowlist to restrict which fields a user can modify via the UI, the RLS policy for the table is insufficiently granular. It grants users with the org.update_settings permission broad authority to perform UPDATE operations on the entire row, rather than restricting access to specific columns.\nThe attack flow proceeds as follows: An authenticated user with org.update_settings privileges identifies that they can interact directly with the underlying Supabase PostgREST API. The attacker crafts a malicious HTTP request directed at the API endpoint, rather than the platform's standard application route. Because the RLS policy checks the user's role and finds they are an organization admin, the policy grants the UPDATE operation regardless of the payload content.\nThe payload includes the customer_id field—a sensitive identifier linking the organization to a specific Stripe billing object. By submitting this request, the attacker successfully overwrites or nulls the customer_id column in the public.orgs table. This bypassing of the secondary permission check (org.update_billing) effectively decouples the organization from its billing record.\nPost-exploitation impact is significant; subsequent requests to the billing verification logic across the capgo.app infrastructure will encounter a missing or corrupted customer_id. This forces the system into a fallback state where the organization is perceived as having no active subscription or being in an invalid billing state. This leads to the immediate loss of access to features restricted to paid plans. The vulnerability persists across all versions of the platform prior to the implementation of column-level security restrictions in the RLS policy. This attack requires network access to the PostgREST interface and requires the attacker to possess an authenticated session with administrative-level, though not billing-level, permissions."
}