CVE-2026-88864 in Capgo
Summary
by MITRE • 09/10/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Capgo involves a critical failure in access control mechanisms within its Supabase PostgREST interface, specifically targeting the public.sso_providers table. This architectural flaw allows any user possessing a standard full API key to directly manipulate database records that are intended to be managed exclusively through secure backend functions and administrative APIs. The core technical issue stems from an insufficient restriction on write permissions for this specific table, which exposes sensitive configuration data regarding Single Sign-On (SSO) providers. By bypassing the application layer logic defined in supabase/functions/_backend/private/sso/providers.ts, attackers can insert rows with status set to active and enforce_sso enabled without undergoing any of the required verification processes. This represents a classic case of broken object level permissions where direct database access circumvents the intended business logic controls designed to ensure data integrity and security compliance.
The operational impact of this vulnerability is severe as it allows an attacker to forge SSO provider configurations for arbitrary domains. Normally, creating an SSO provider requires adherence to strict enterprise-level protocols including DNS TXT domain-ownership verification, a mandatory status transition from pending_verification to verified before reaching active state, and the issuance of trusted provider IDs by Supabase Auth services. However, due to this flaw, an attacker can bypass these steps entirely. By inserting a row with enforced SSO settings for a target domain that has not been verified, the system incorrectly assumes legitimate ownership and configuration authority over that domain's authentication flow. This manipulation disrupts normal login procedures because the application begins enforcing SSO requirements based on forged data rather than validated administrative actions.
This misconfiguration directly impacts the unauthenticated login preflight endpoint located at /private/sso/check-domain. When this endpoint is queried for a domain targeted by an attacker, it returns a response indicating has_sso as true and enforce_sso as true despite no actual SSO provider being legitimately configured or verified for that domain. Consequently, users attempting to log in may be redirected to non-existent or maliciously controlled identity providers, leading to denial of service conditions where legitimate access is blocked. Furthermore, this could potentially facilitate phishing attacks if the attacker configures a rogue SSO endpoint to capture credentials under the guise of a trusted enterprise login process. The lack of input validation and authorization checks on direct API calls allows for complete subversion of the authentication infrastructure's integrity.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management as it involves unauthorized elevation of privileges through direct database manipulation rather than proper application-level controls. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource since the public.sso_providers table is exposed without adequate restrictions on who can modify its contents. In terms of attack vectors, this falls under ATT&CK technique T1098 Unauthorized Account Modification where an adversary manipulates account or service configurations to maintain access or disrupt operations. The ability to enforce SSO for arbitrary domains effectively allows the attacker to hijack authentication flows, which is a significant threat to organizational security postures relying on centralized identity management.
Mitigation strategies must focus on immediate remediation of database permissions and implementation of robust backend validation layers. Since no patch was available at the time of disclosure, administrators should immediately revoke or rotate any Capgo full API keys that are not strictly necessary for core operations. It is crucial to restrict write access to the sso_providers table so that only internal service accounts with elevated privileges can modify these records. Additionally, implementing row-level security policies within Supabase PostgREST would prevent direct insertion of active SSO configurations by standard users. Application-layer validation should be reinforced to ensure that any changes to SSO settings trigger mandatory domain verification checks and status transitions before being accepted as valid configuration data. Regular audits of database permissions and API endpoint access controls are essential to prevent similar privilege escalation vulnerabilities in the future.