Threat Intelligence Report — CVE-2026-88864

Executive Summary

CVE-2026-88864 is an improper access control vulnerability (CWE-284) in Capgo (capgo.app) that allows any holder of an ordinary full API key to bypass the intended SSO provider provisioning backend by directly inserting attacker-controlled rows into the public.sso_providers table exposed via Supabase PostgREST. Because the forged row is trusted by SSO discovery and enforcement logic — including the unauthenticated login preflight endpoint /private/sso/check-domain — an attacker can assert has_sso: true and enforce_sso: true for arbitrary, unverified domains, disrupting normal authentication flows. The vulnerability carries a CVSS 3.1 base score of 9.1 (Critical) and, at the time of the advisory, no patch was available.

Technical Analysis

Capgo is a live-update / over-the-air (OTA) delivery platform commonly deployed on top of Supabase. Its enterprise SSO feature is implemented through a backend Supabase Edge Function located at supabase/functions/_backend/private/sso/providers.ts. That backend route is designed to be the only legitimate path through which an SSO provider row may be created, and it enforces a chain of controls:

1. Enterprise plan requirement — only tenants on an Enterprise plan are permitted to provision SSO providers.
2. Creation via the Supabase Management API — provider records are meant to be written through the managed control plane, not directly to the database.
3. DNS TXT domain-ownership verification — the requesting party must prove control of the target domain.
4. Status lifecycle enforcement — a provider must transition pending_verification → verified → active, preventing premature activation.
5. Trusted provider ID issuance — a provider ID must be issued by Supabase Auth, binding the record to an authenticated identity.

The core defect is that the public.sso_providers table is exposed through Supabase PostgREST, and the database does not restrict direct write access to it. PostgREST auto-generates a REST interface over exposed tables, so any principal that can reach the PostgREST endpoint with a token that passes row-level/role checks can issue a direct INSERT. In this case, the privilege boundary is misconfigured: a holder of a merely ordinary Capgo full API key — not an Enterprise administrator, and without ever touching the backend function — can perform the insert.

The attacker inserts a row with status='active' and enforce_sso=true. These two column values are exactly the states the legitimate backend would only reach after all five controls above have passed. By writing the terminal state directly, the attacker short-circuits every control simultaneously: there is no Enterprise check, no Management API mediation, no DNS TXT verification, no pending_verification stage, and no Supabase Auth-issued trusted provider ID.

The forged row is subsequently trusted by the SSO discovery and enforcement logic. The most damaging consumer is the unauthenticated login preflight endpoint /private/sso/check-domain, which reads sso_providers and, for a matching domain, returns:

{"has_sso": true, "enforce_sso": true}

This means the attacker can make Capgo report that single sign-on is required — and enforced — for a domain that was never verified and for which no legitimate provider exists. Because the preflight is unauthenticated, the attacker requires no session to benefit from the poisoned state; the poisoning itself requires only an ordinary API key.

Two distinct weaknesses compound here:

• Write-path over-exposure (CWE-284): a sensitive table with security-state columns is writable outside the intended privilege boundary.
• Trust of self-asserted security state: downstream logic (including an unauthenticated endpoint) treats sso_providers content as authoritative without re-validating plan, DNS ownership, lifecycle, or provider-ID authenticity.

CVSS 3.1 reflects this structure: network vector (AV:N), low attack complexity (AC:L), low privileges required (PR:L, i.e. an ordinary API key), no user interaction (UI:N), changed scope (S:C — impact crosses from the API-key holder's tenant into the authentication domain of third parties), low confidentiality (C:L), high integrity (I:H — forged security state), and low availability (A:L — login disruption/lockout of legitimate users).

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template is available. The chain below is inferred from the vulnerability class (improper access control over a PostgREST-exposed table) and the components named in the advisory. No specific implementation details beyond those in the description are asserted.

1) Reconnaissance / target identification. The attacker identifies a Capgo deployment and the Supabase project backing it. The PostgREST surface and the unauthenticated /private/sso/check-domain preflight are discoverable: the preflight is explicitly unauthenticated, so its behavior — including has_sso/enforce_sso responses — can be probed without credentials. The attacker confirms the target domain(s) they wish to poison.

2) Triggering the specific flaw class. The attacker obtains an ordinary Capgo full API key. The advisory states this is sufficient — no Enterprise plan, no administrative role, and no backend function invocation is required. The attacker issues a direct write to the public.sso_providers table through the Supabase PostgREST interface, rather than calling the intended route at supabase/functions/_backend/private/sso/providers.ts. The write is accepted because the table is exposed and direct write access is not restricted.

3) Payload / execution at the vulnerability-class level. The inserted row sets status='active' and enforce_sso=true, with the target domain. This bypasses, in a single operation:

• the Enterprise plan requirement,
• provider creation via the Supabase Management API,
• DNS TXT domain-ownership verification,
• the pending_verification → verified → active transition,
• issuance of a trusted provider ID by Supabase Auth.

The database now contains a self-asserted, fully "active" SSO provider for a domain the attacker never proved ownership of, with no Supabase Auth-issued provider ID binding it to a real identity.

4) Post-exploitation impact. The forged row is trusted by SSO discovery and enforcement logic. When the unauthenticated /private/sso/check-domain preflight is queried for the poisoned domain, it returns {"has_sso": true, "enforce_sso": true}. Consequences:

• SSO enforcement asserted for arbitrary domains — clients are told SSO is mandatory for domains that were never verified.
• Login disruption / denial of service — legitimate users of the affected domain are redirected into or blocked by an SSO path that has no legitimate, trusted provider, disrupting normal authentication. This maps to the A:L availability impact.
• Integrity compromise of authentication state (I:H) — the security posture reported to clients no longer reflects verified reality, enabling downstream misrouting, social-engineering footholds, or coercion of users toward attacker-influenced authentication flows (scope is changed, S:C, because it affects parties beyond the key holder).
• Because the endpoint is unauthenticated, the poisoned enforcement state is observable and exploitable by anyone who queries the domain.

No public exploit tooling exists; this remains a reasoned attacker workflow from the described flaw, not a weaponized chain.

Impact Assessment

• Confidentiality (C:L): Limited direct data exposure; the primary risk is the ability to observe/enumerate SSO enforcement state and potentially leak domain existence via the unauthenticated preflight.
• Integrity (I:H): The dominant impact. Attacker-controlled security state (status='active', enforce_sso=true) is injected into the table that governs SSO discovery and enforcement. This is a forgery of authentication/authorization metadata.
• Availability (A:L): Login for affected domains can be disrupted or degraded as users are forced into a non-functional or untrusted SSO enforcement path.
• Scope (S:C): Impact crosses a trust boundary — from the API-key holder into the authentication posture of arbitrary third-party domains, so defenses on the Capgo tenant do not contain the effect.
• Privileges (PR:L): Only an ordinary full API key is required, materially lowering the bar for exploitation.

Blast radius: Any Capgo deployment that uses Supabase PostgREST to expose public.sso_providers and relies on the affected SSO enforcement logic is at risk. Because enforcement can be asserted for arbitrary domains, victims need not be Capgo customers themselves — third-party organizations whose domains are abused via the preflight can be affected. The vulnerability is network-reachable, low-complexity, requires no user interaction, and crosses scope, consistent with the CVSS 9.1 base score. No CISA KEV listing and no EPSS score (not yet scored by FIRST.org) are available; treat as actively ageable given trivial preconditions.

Detection Guidance

Because exploitation manifests as a PostgREST write to sso_providers and reads to the unauthenticated preflight, detection should combine database/write monitoring, HTTP telemetry, and cloud audit logging.

Sigma Rule

title: Capgo SSO Provider Table Direct Write via Supabase PostgREST
id: 3f9c1a2e-capgo-sso-284
status: experimental
description: Detects direct INSERT/UPDATE against public.sso_providers through Supabase PostgREST that sets enforce_sso=true or status=active outside the backend providers.ts route (CVE-2026-88864).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-88864
author: valtersit.com Threat Intelligence
logsource:
  product: supabase
  service: postgrest
detection:
  selection_method:
    http.method:
      - POST
      - PATCH
      - PUT
  selection_endpoint:
    url.path|contains:
      - '/rest/v1/sso_providers'
  selection_payload:
    http.request.body|contains:
      - 'enforce_sso'
      - 'status'
      - 'active'
  condition: selection_method and selection_endpoint and selection_payload
fields:
  - user
  - url.path
  - http.request.body
  - source.ip
falsepositives:
  - Legitimate backend provisioning through supabase/functions/_backend/private/sso/providers.ts (distinguish by source / user agent / role)
level: high

YARA Rule

rule CVE_2026_88864_Capgo_SSO_Provider_Forge
{
    meta:
        description = "Detects PostgREST write payloads forging Capgo SSO provider state (CVE-2026-88864)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-88864"
        severity = "high"
        date = "2026-01-01"

    strings:
        $table   = "sso_providers" ascii wide nocase
        $enforce = "enforce_sso" ascii wide nocase
        $status  = "status" ascii wide nocase
        $active  = "active" ascii wide nocase
        $check   = "/private/sso/check-domain" ascii wide nocase

    condition:
        uint32(0) == 0x4D5A or
        ( ($table and $enforce and $active) or
          ($table and $status and $active and $enforce) or
          ($check and $enforce) )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-88864 Capgo SSO Provider Forge via Supabase PostgREST"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/rest/v1/sso_providers"; http.request_body; content:"enforce_sso"; http.request_body; content:"active"; classtype:web-application-attack; reference:cve,2026-88864; sid:202688864; rev:1;)

alert http any any -> any any (msg:"CVE-2026-88864 Capgo SSO Check-Domain Preflight Probe"; flow:established,to_server; http.uri; content:"/private/sso/check-domain"; classtype:web-application-activity; reference:cve,2026-88864; sid:202688865; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where network.protocol == "http" and
      http.request.method in ("POST","PATCH","PUT") and
      url.path : "*sso_providers*" and
      http.request.body.text : ("*enforce_sso*" and "*active*") ]
  [ network where network.protocol == "http" and
      url.path : "*check-domain*" ]

Standalone event fallback:

network where network.protocol == "http" and url.path : "*sso_providers*" and
  http.request.method in ("POST","PATCH","PUT") and
  http.request.body.text : ("*enforce_sso*") and http.request.body.text : ("*active*")

Splunk SPL Query

index=web OR index=supabase sourcetype IN (access_combined, postgrest, supabase:postgrest)
| eval is_write=if(match(http_method,"POST|PATCH|PUT") AND match(uri,"/rest/v1/sso_providers"),1,0)
| eval forges_state=if(match(request_body,"enforce_sso") AND match(request_body,"active"),1,0)
| where is_write=1 OR forges_state=1 OR match(uri,"/private/sso/check-domain")
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as uris values(request_body) as bodies by src_ip
| sort - count

Wazuh OSSEC Rule

<group name="capgo,web,cve-2026-88864,">
  <rule id="202688864" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <url>/rest/v1/sso_providers</url>
    <description>CVE-2026-88864: Direct write to Capgo sso_providers table via Supabase PostgREST (potential SSO provider forgery)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web_application_attack,</group>
  </rule>

  <rule id="202688865" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <url>/private/sso/check-domain</url>
    <description>CVE-2026-88864: Access to Capgo unauthenticated SSO check-domain preflight (possible enforcement manipulation/abuse)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web_application_activity,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence was available from any tracked source at the time of the advisory; no affected-version fix, vendor fix, or workaround was published. The following are defensive recommendations, not vendor-confirmed fixes.

1) Immediate mitigations (apply now):

• Revoke and rotate ordinary Capgo full API keys that are not strictly required, and audit all holders of such keys. The advisory treats an ordinary full API key as sufficient for exploitation.
• Remove direct write access to public.sso_providers in Supabase. Restrict PostgREST exposure of the table and tighten row-level security / table grants so that only the intended backend principal (the route at supabase/functions/_backend/private/sso/providers.ts) can INSERT/UPDATE. Deny direct writes from ordinary API keys.
• Audit the sso_providers table for rows not matching the legitimate lifecycle — e.g., rows already at status='active' or enforce_sso=true that never passed pending_verification → verified → active, or rows lacking a Supabase Auth-issued trusted provider ID. Quarantine/delete forged rows and restore verified state.
• Monitor /private/sso/check-domain for domains that were never DNS-TXT verified returning {"has_sso": true, "enforce_sso": true}; treat unexpected enforcement for unverified domains as compromise of the table.
• Consider temporarily disabling SSO enforcement for affected tenants until the table is cleaned and writes are locked down, to restore login for impacted users.

2) Patch / upgrade steps:

• No official patch exists (0/4). Track the vendor (Capgo, capgo.app) and NVD for a fixed release. When available, upgrade immediately and re-validate that sso_providers writes route exclusively through supabase/functions/_backend/private/sso/providers.ts.
• Until then, treat the configuration-level mitigations in section 1 as the primary remediation.

3) Long-term hardening:

• Enforce deny-by-default PostgREST exposure: never expose security-state tables to the auto-generated REST API; use explicit RLS policies and least-privilege roles.
• Require all SSO provider mutations to pass server-side validation that re-checks plan tier, DNS TXT ownership, lifecycle state, and Supabase Auth provider-ID authenticity at read time, so a self-asserted database row can never be trusted by enforcement logic.
• Add integrity constraints so terminal states (active, enforce_sso=true) cannot be written without the preceding verified transition and a valid trusted provider ID.
• Rotate API keys on a schedule; scope "full" keys narrowly; log and alert on all writes to security-sensitive tables.
• Continuously probe /private/sso/check-domain for unauthorized enforcement assertions and feed results into detection pipelines.

References

• NVD — CVE-2026-88864: https://nvd.nist.gov/vuln/detail/CVE-2026-88864
• Capgo (capgo.app) — vendor product site / security advisories: https://capgo.app
• Supabase — PostgREST and Row Level Security documentation (exposure and RLS guidance): https://supabase.com/docs
• CWE-284 — Improper Access Control: https://cwe.mitre.org/data/definitions/284.html
• MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Exploit-in-the-wild / threat actor activity: None reported. CISA KEV: NO. EPSS: not yet scored by FIRST.org. No public PoC, exploit code, or Nuclei template observed.