CVE-2026-88861
HighCVSS 8.3Exploitation Probability (EPSS)
Low risk42th percentile - higher than 42% of all known CVEs
Summary
Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions. The Edge authorization path accepts a password-only Supabase aal1 session and grants RBAC permissions even when the account has a verified MFA factor that was not used for the session.
Risk Assessment
An attacker who knows only the victim's password can authenticate, mint a persistent app_admin API key, and perform privileged operations such as modifying production OTA channel configurations, fully defeating MFA protection. No patched version is available.
Recommendation
Track the Capgo patch release and apply it immediately upon publication. Until then, consider enforcing additional access controls and monitoring API key creation and production channel changes.
Other vulnerabilities in Capgo
See all- CVE-2026-88863High
The npm package `capgo` (through version 12.207.1) fails to compare the caller's role rank against the requested role in validateInvite(). A user holding only the org.invite_user permission can invite an external user as org_admin or org_billing_admin, and accepting the invitation creates the role binding while bypassing database protection triggers.
- CVE-2026-56329Medium
A vulnerability in Capgo before version 12.128.2 is caused by non-bijective decoding of double underscores to dots in preview hostname parsing. Attackers can register app IDs with underscores that collide with other tenants' dotted app IDs, leading to preview misrouting and denial of preview access for victim applications.
- CVE-2026-56279High
A vulnerability in Capgo before version 12.128.2 discloses information via the get_orgs_v7(userid) RPC function, which remains publicly invokable despite intended private access controls. Unauthenticated attackers can supply arbitrary user UUIDs to retrieve foreign users' organization membership, roles, management emails, and billing metadata.
- CVE-2026-56293Medium
A vulnerability in Capgo before version 12.128.2 stems from an authorization flaw in the transfer_app() function that fails to update the deploy_history.owner_org field when transferring applications between organizations. Attackers can exploit this omission to retain unauthorized access to deployment history records in the source organization or cause the destination organization to lose access to transferred application deployment records.
- CVE-2026-56250High
A vulnerability in Capgo before version 12.128.2 allows upload-scoped API keys to modify the app_versions.r2_path field via PostgREST, enabling retargeting to arbitrary R2 bundle objects. Attackers can patch r2_path to point to victim objects, soft-delete the attacker-controlled version, and trigger the on_version_update cleanup function to delete the victim R2 object, causing denial of service and bundle availability disruption.
- CVE-2026-56246High
A broken access control vulnerability in Capgo before version 12.128.2 allows a scoped API key (limited_to_orgs) to inherit its owner's user permissions, enabling destructive cross-organization actions. A write-mode API key restricted to one organization can still perform operations like DELETE /organization or DELETE /organization/members against another organization.
- CVE-2026-56322High
Capgo before 12.128.2 contains an information disclosure vulnerability in the unauthenticated /updates endpoint that resolves the defaultChannel parameter before enforcing privacy restrictions. This allows attackers to enumerate private channels and leak version/config state.
- CVE-2026-56234Medium
Capgo before version 12.128.2 contains a credential validation vulnerability in the POST /functions/v1/private/validate_password_compliance endpoint that can be called using only the public Supabase key without authentication. The endpoint is CORS-permissive and lacks rate limiting, enabling attackers to perform password spraying and credential stuffing attacks.
- CVE-2026-88864Critical
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 and its controls (Enterprise plan requirement, SSO provider creation via 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 reports {"has_sso": true, "enforce_sso": true} for domains that were never verified.
- CVE-2026-100629Medium
Capgo (capgo.app backend) before 12.127.5 contains an authorization flaw in the PATCH /private/role_bindings/:binding_id endpoint. The handler verifies that the newly assigned role's priority rank does not exceed the caller's own rank, but never checks the rank of the role currently bound to the target binding, allowing an org_admin (rank 90) to demote an org_super_admin binding (rank 95) to a lower-privileged role such as org_member (rank 75).
Original NVD description (English source)
Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions (no patched version available at time of publication). The Edge authorization path allows a password-only Supabase aal1 session to exercise privileged RBAC permissions even when the account has a verified MFA factor that has not been used for the session: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts the JWT without validating its assurance level, and the direct RBAC path (checkPermission()/checkPermissionPg() in supabase/functions/_backend/utils/rbac.ts calling public.rbac_check_permission_direct()) authorizes by user ID without passing or checking the session aal, unlike the public.verify_mfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped app_admin API key that remains valid after the aal1 session is logged out, and perform privileged operations such as modifying production OTA channel configurations (validated by changing a public production channel from bundle 1.0.0 to 1.0.1), defeating the protection provided by MFA.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

