Capgo App
Monthly
Improper access control in Capgo (capgo.app) lets any holder of an ordinary full API key forge a trusted SSO provider by writing directly to the public.sso_providers table exposed via Supabase PostgREST, setting status='active' and enforce_sso=true without passing the backend provisioning route. This sidesteps the Enterprise-plan gate, Supabase Management API provider creation, DNS TXT domain-ownership verification, and the pending_verification→verified→active workflow, so an attacker can assert SSO enforcement for arbitrary unverified domains and disrupt normal login. All versions are affected, no patch was available at advisory time, and there is no public exploit identified at time of analysis beyond the VulnCheck write-up.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Privilege escalation in the Capgo (capgo.app) backend through version 12.242.4 allows an authenticated API key holder to impersonate a more privileged sibling key by supplying its numeric ID in the `x-limited-key-id` header, bypassing the intended parent-child delegation hierarchy entirely. The middleware's `checkKeyByIdPg()` resolves the caller-supplied key ID using only the ID, expiration state, and owning `user_id`, while `validateSubkeyUser()` only checks that both keys share an owner - neither function verifies that the resolved key is an actual descendant of the authenticating key. An `apikey_manager` key can therefore silently acquire `app_admin` permissions via `setSubkeyAuthContext` without knowledge of the target key's secret; the issue was confirmed on release 12.242.4 after a prior incomplete fix (GHSA-8h52-44r7-w343), and no patched version was available at time of advisory.
Capgo's MFA enforcement is defeated by an authentication assurance level (AAL) mismatch across two distinct code paths: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts Supabase JWTs without inspecting the aal claim, and the direct RBAC path (checkPermissionPg() calling public.rbac_check_permission_direct() in rbac.ts) authorizes operations by user ID alone, bypassing the assurance-level check that public.verify_mfa() correctly enforces. An attacker holding only the victim's account password can authenticate, receive an aal1 JWT, exercise privileged RBAC operations without triggering any MFA challenge, mint a persistent app_admin API key, and modify production OTA channel configurations - all of which survive logout of the original aal1 session. No patched version has been released; all versions of capgo.app are affected, and the advisory includes a validated proof-of-concept demonstrating bundle swap on a production channel.
Authorization bypass in Capgo (capgo.app), a live-update/OTA platform for Capacitor mobile apps, allows a de-provisioned user to retain channel-level permissions after their organization RBAC access has been revoked. Because Capgo does not clean up channel permission overrides when a user's last organization role binding is deleted, stale grants remain active - letting the former member perform privileged actions such as pushing or changing production OTA update versions. Reported by VulnCheck (GHSA-qfxq-2ch8-hjg9); no public exploit identified at time of analysis.
Improper access control in Capgo (capgo.app) lets any holder of an ordinary full API key forge a trusted SSO provider by writing directly to the public.sso_providers table exposed via Supabase PostgREST, setting status='active' and enforce_sso=true without passing the backend provisioning route. This sidesteps the Enterprise-plan gate, Supabase Management API provider creation, DNS TXT domain-ownership verification, and the pending_verification→verified→active workflow, so an attacker can assert SSO enforcement for arbitrary unverified domains and disrupt normal login. All versions are affected, no patch was available at advisory time, and there is no public exploit identified at time of analysis beyond the VulnCheck write-up.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Privilege escalation in the Capgo (capgo.app) backend through version 12.242.4 allows an authenticated API key holder to impersonate a more privileged sibling key by supplying its numeric ID in the `x-limited-key-id` header, bypassing the intended parent-child delegation hierarchy entirely. The middleware's `checkKeyByIdPg()` resolves the caller-supplied key ID using only the ID, expiration state, and owning `user_id`, while `validateSubkeyUser()` only checks that both keys share an owner - neither function verifies that the resolved key is an actual descendant of the authenticating key. An `apikey_manager` key can therefore silently acquire `app_admin` permissions via `setSubkeyAuthContext` without knowledge of the target key's secret; the issue was confirmed on release 12.242.4 after a prior incomplete fix (GHSA-8h52-44r7-w343), and no patched version was available at time of advisory.
Capgo's MFA enforcement is defeated by an authentication assurance level (AAL) mismatch across two distinct code paths: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts Supabase JWTs without inspecting the aal claim, and the direct RBAC path (checkPermissionPg() calling public.rbac_check_permission_direct() in rbac.ts) authorizes operations by user ID alone, bypassing the assurance-level check that public.verify_mfa() correctly enforces. An attacker holding only the victim's account password can authenticate, receive an aal1 JWT, exercise privileged RBAC operations without triggering any MFA challenge, mint a persistent app_admin API key, and modify production OTA channel configurations - all of which survive logout of the original aal1 session. No patched version has been released; all versions of capgo.app are affected, and the advisory includes a validated proof-of-concept demonstrating bundle swap on a production channel.
Authorization bypass in Capgo (capgo.app), a live-update/OTA platform for Capacitor mobile apps, allows a de-provisioned user to retain channel-level permissions after their organization RBAC access has been revoked. Because Capgo does not clean up channel permission overrides when a user's last organization role binding is deleted, stale grants remain active - letting the former member perform privileged actions such as pushing or changing production OTA update versions. Reported by VulnCheck (GHSA-qfxq-2ch8-hjg9); no public exploit identified at time of analysis.