CVE-2026-100623: Capgo Authentication Bypass via Direct PostgREST org_users Table Write
Capgo (capgo.app) exposes the legacy membership table public.orgusers directly through Supabase PostgREST. The table's row-level security policies "Allow org admin to insert" and "Allow org admin to update" only verify that the caller has admin rights in the target organization (public.checkminrights('admin', ...)); they do not require a pending invitation in tmpusers, acceptance of an invite token via /private/acceptinvitation, any action by the target user, or the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. As a result, an authenticated user who is an admin of an organization can INSERT or UPDATE orgusers rows directly to add any existing public.users account as an active member of that organization with userright="admin", bypassing the invitation and role-assignment workflow entirely. In testing, an account with no prior access to the organization or its apps could, after such a direct insert, read the organization and app and pass checkminrights. All versions are affected and no patch was available at the time of publication.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated Capgo user who already has admin rights in an organization can exploit it. They can directly insert or update membership rows for any existing public.users account.
Does exploitation require an invitation or action by the account being added?
No. The direct PostgREST write bypasses the pending-invitation, invite-token acceptance, target-user action, and role-consistency checks in the normal workflow.
What access can be granted through the vulnerable path?
The organization admin can add an existing account as an active organization member with user_right set to admin. Testing showed that an account previously lacking access could then read the organization and its apps and satisfy check_min_rights.
Are default deployments affected, and is a patch available?
All versions are affected. No patch was available at the time of publication.
What can be checked to identify possible abuse?
Review public.org_users for membership rows, especially active admin memberships, that lack a corresponding pending invitation or accepted invite-token workflow. Also investigate direct INSERT or UPDATE activity against that table by organization administrators.