CVE-2026-100616 in capgo.app
Summary
by MITRE • 09/26/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in capgo.app, an over-the-air update platform for Capacitor applications, represents a critical failure in database-level access control that allows privilege escalation and data integrity compromise through row-level security bypasses. The core technical flaw resides within the public.orgs table configuration, specifically concerning its UPDATE policy under Row-Level Security (RLS). Although the application logic implemented via the official organization update endpoint at supabase/functions/_backend/public/organization/put.ts correctly restricts editable fields to a small set of settings and explicitly excludes sensitive internal columns such as customer_id, this application-level validation is circumvented by interacting directly with the underlying Supabase PostgREST API. This architectural separation between the application layer and the database interface creates an attack surface where authenticated users can bypass business logic constraints if they possess sufficient privileges at the database row level.
An organization administrator holding the org.update_settings permission possesses the authority to execute UPDATE operations on rows within the public.orgs table associated with their organization. Due to a misconfiguration in the RLS policy, this permission grants broad write access that encompasses all columns in the row, including the internal billing pointer column customer_id. This design flaw effectively allows an admin user who lacks the specific org.update_billing permission to modify or nullify the Stripe customer identifier linked to the organization. By sending a direct HTTP PUT request to the PostgREST endpoint with modified data for the customer_id field, an attacker can corrupt this critical reference without triggering any of the intended authorization checks that would normally occur through the official API endpoints.
The operational impact of this vulnerability is severe and directly affects the billing infrastructure and service availability for affected organizations. The system relies on the orgs.customer_id column to validate subscription status and enforce plan-based access controls. When an attacker nullifies or corrupts this pointer, subsequent billing checks that depend on the presence and validity of a Stripe customer ID will fail. This failure causes the platform to incorrectly classify the organization as having no active paid plan, effectively downgrading them from a valid paid state to an unpaid or free-tier status. Consequently, users may lose access to premium features, experience service interruptions, or face incorrect billing states that require manual intervention by support staff to resolve, thereby undermining trust in the platform's security and reliability mechanisms.
From a standards perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as it involves an actor obtaining capabilities beyond their intended role through misconfigured database policies rather than application logic errors alone. It also relates closely to CWE-862 Missing Authorization, specifically in the context of horizontal privilege escalation where a user modifies data they should not be able to touch due to insufficient checks on specific fields within a broader permission set. In terms of MITRE ATT&CK mapping, this behavior is consistent with T1078 Valid Accounts and potentially T1190 Exploit Public-Facing Application if the PostgREST endpoint is considered public-facing, although it primarily demonstrates how valid credentials can be leveraged to manipulate data integrity when underlying security controls are not strictly enforced at every layer of the stack.
Mitigation strategies must address both the immediate database configuration and broader architectural patterns to prevent recurrence. The primary fix involves tightening the Row-Level Security policies on the public.orgs table to explicitly restrict UPDATE operations to only those columns that are safe for organization admins to modify, thereby excluding sensitive fields like customer_id from any update policy granted by org.update_settings. Additionally, implementing strict input validation and field allowlisting at the PostgREST level or via database functions can ensure that even direct API calls adhere to the same business logic constraints as the official endpoints. Organizations should also audit their RLS policies regularly to ensure they follow the principle of least privilege, ensuring that permissions granted for one administrative function do not inadvertently expose unrelated sensitive data fields. Until such patches are deployed and verified through penetration testing, monitoring logs for unusual UPDATE patterns on the orgs table can help detect potential exploitation attempts in real-time.