Description

Capgo (capgo.app) fails to restrict direct write access to the public.sso_providers table exposed through Supabase PostgREST. A holder of an ordinary Capgo full API key can insert a row with status='active' and enforce_sso=true, bypassing the intended backend SSO provisioning route (supabase/functions/_backend/private/sso/providers.ts) and its controls: the Enterprise plan requirement, SSO provider creation via the Supabase Management API, DNS TXT domain-ownership verification, the pending_verification → verified → active status transition, and issuance of a trusted provider ID by Supabase Auth. The forged row is trusted by SSO discovery and enforcement logic, including the unauthenticated login preflight endpoint /private/sso/check-domain, which then reports {"has_sso": true, "enforce_sso": true} for domains that were never verified, allowing attacker-controlled SSO enforcement to be asserted for arbitrary domains and disrupting normal login. All versions are affected; at the time of the advisory no patch was available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-10T14:17:12.187Z",
  "pubdate": "2026-09-10T14:17:12.187Z",
  "executiveSummary": "Capgo (capgo.app) is vulnerable to an Insecure Direct Object Access (IDOA) vulnerability stemming from improper access control configurations in the Supabase PostgREST API.\nThe vulnerability allows an attacker possessing a standard Capgo API key to bypass critical business logic by directly writing to the 'public.sso_providers' table.\nBy injecting unauthorized rows into this table, an attacker can circumvent Enterprise plan requirements, domain-ownership verification (DNS TXT checks), and the mandatory Supabase Management API provisioning process.\nThis exploit allows the unauthorized assertion of SSO enforcement for arbitrary domains. Consequently, attackers can disrupt legitimate user authentication flows, deny service to users by forcing non-existent SSO providers, and potentially facilitate account takeovers or credential harvesting through malicious SSO discovery responses.\nThe vulnerability affects all versions of Capgo, as the underlying architecture fails to enforce Row-Level Security (RLS) or backend proxying for sensitive configuration tables.",
  "technicalDetails": "The root cause of this vulnerability is the exposed write access to the 'public.sso_providers' table via the Supabase PostgREST interface. The backend logic intended to manage SSO providers is located in 'supabase/functions/_backend/private/sso/providers.ts'; however, because the underlying database table is directly accessible via the public API, an attacker can circumvent these programmed controls entirely.\nThe exploitation flow initiates when an attacker utilizes an ordinary, low-privilege Capgo API key to perform an authorized 'INSERT' or 'UPDATE' request against the 'public.sso_providers' table. By constructing a payload containing 'status=active' and 'enforce_sso=true', the attacker bypasses the entire provisioning lifecycle. This lifecycle should include Enterprise plan validation, domain ownership verification via DNS TXT records, and the necessary handshake with the Supabase Management API to issue a trusted provider ID.\nThe application relies on this table for its 'unauthenticated' login preflight endpoint, specifically '/private/sso/check-domain'. Because the application trusts the database state directly, the preflight endpoint will ingest the attacker-injected row and return a JSON response indicating {'has_sso': true, 'enforce_sso': true} for any target domain provided by the attacker.\nOnce the forged record is persisted in the database, the system treats it as a legitimate configuration. The impact is significant: first, it allows for widespread denial-of-service against user login flows for arbitrary domains. Second, it misleads the client-side application logic into enforcing SSO authentication protocols that do not exist or are controlled by the attacker. Since the system fails to validate the record against the actual Supabase Auth provider infrastructure, the trust model is effectively broken. The vulnerability demonstrates a failure to implement Row-Level Security (RLS) on sensitive administrative tables, allowing any authenticated user to modify the global identity management configuration of the platform."
}