Capgo EUVD-2026-75414

Exploitation requires the attacker to possess a valid ordinary Capgo full API key (any registered account) and requires that the public.sso_providers table remain directly writable through Supabase PostgREST - the default condition described, since no authorization restricts writes to the backend route. The attacker then inserts a forged provider row (status='active', enforce_sso=true) for a chosen domain with no need for Enterprise entitlement, Supabase Management API access, DNS TXT ownership proof, or the normal pending→verified→active transition. The limiting factor is the API-key requirement (so this is authenticated, not anonymous, despite the published PR:N); once the row exists, the downstream /private/sso/check-domain effect is observable unauthenticated.

The CVSS 4.0 base score of 9.3 is driven by AV:N/AC:L/PR:N with high VC/VI/VA, but the description makes clear the attacker must already hold a valid Capgo full API key, so PR:N overstates the precondition - this is authenticated abuse (realistically PR:L), not fully anonymous exploitation. The true impact is to integrity (forging trusted SSO configuration) and availability (asserting enforce_sso on arbitrary domains breaks normal login for those users); confidentiality impact is marginal, limited to a boolean leaked by check-domain. No EPSS score, KEV listing, or public PoC is provided, so there is no evidence of active exploitation, though VulnCheck's advisory documents the exact method and the write is trivially automatable once a key is obtained. Net: a genuine high-priority authorization flaw for any Capgo-dependent operator - even a mid-sized operator in olsztyn should treat a login-disruption primitive against unverified domains as urgent - but defenders should weight it by the API-key prerequisite and the absence of confirmed in-the-wild activity rather than the raw 9.3.

An attacker registers a normal Capgo account, obtains a full API key, and issues a direct PostgREST INSERT into public.sso_providers for a victim's corporate domain with status='active' and enforce_sso=true. The unauthenticated /private/sso/check-domain preflight then returns {"has_sso": true, "enforce_sso": true} for that domain, redirecting or blocking legitimate users into an SSO flow that was never provisioned and disrupting their logins. The VulnCheck advisory documents this method, though no separate public exploit tool is cited.