Description

Capgo (capgo.app) exposes the legacy membership table public.org_users 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.check_min_rights('admin', ...)); they do not require a pending invitation in tmp_users, acceptance of an invite token via /private/accept_invitation, 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 org_users rows directly to add any existing public.users account as an active member of that organization with user_right="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 check_min_rights. All versions are affected and no patch was available at the time of publication.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-26T14:16:43.293Z",
  "pubdate": "2026-09-26T14:16:43.293Z",
  "executiveSummary": "Capgo (capgo.app) suffers from an Improper Authorization vulnerability within its database layer, specifically involving direct access to the 'public.org_users' table via Supabase PostgREST.\nThe vulnerability allows an authenticated organization administrator to bypass critical security workflows, including user invitation and role-assignment validation, by directly inserting or updating records in the membership table.\nBy manipulating the 'public.org_users' table, an attacker can arbitrarily add any existing user to an organization with 'admin' privileges, effectively granting unauthorized access to the organization's private applications and data.\nThis flaw exists because the Row-Level Security (RLS) policies fail to enforce consistency with the 'tmp_users' invitation workflow and the established RBAC role-binding architecture.\nThe risk is critical, as it enables horizontal and vertical privilege escalation without the target user's interaction or consent.\nThe vulnerability affects all versions of the platform, with no automated patch mechanisms currently available.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the Row-Level Security (RLS) policies governing the 'public.org_users' table. While the 'Allow org admin to insert' and 'Allow org admin to update' policies verify the caller's admin status using 'public.check_min_rights('admin', ...)', they lack comprehensive validation logic.\nSpecifically, the RLS policies fail to cross-reference the proposed membership change against the 'tmp_users' table, which acts as the controlled conduit for invitations. Furthermore, the policies do not enforce the application of 'user_right' values through the platform's standard business logic (e.g., /private/accept_invitation), which would typically validate role-binding constraints and prevent unauthorized privilege escalation.\nThe attack flow proceeds as follows: An attacker, already possessing 'admin' rights within a Capgo organization, leverages the exposed PostgREST API to interact directly with the 'public.org_users' table. Because the RLS policy only validates the requester's admin status rather than the integrity of the membership request itself, the attacker can submit a direct INSERT or UPDATE payload.\nBy crafting a request to add the unique identifier of an arbitrary, existing 'public.users' account into the target organization with a 'user_right' set to 'admin', the attacker successfully bypasses the entire invitation workflow. The database engine permits this operation because the caller meets the basic 'admin' check, regardless of the target user's prior relationship with the organization.\nPost-exploitation, the newly added user account inherits full organizational administrative privileges. The target account, often without their knowledge, is granted access to the organization's resources, including its applications. Because this action populates the 'org_users' table, the platform's internal logic—specifically 'check_min_rights'—subsequently recognizes the target user as a legitimate 'admin', allowing them to perform administrative actions, access application data, and further compromise the organization's security posture.\nThis vulnerability effectively weaponizes the PostgREST API against the underlying RBAC implementation, rendering established workflow controls moot and exposing all organization-level data to unauthorized accounts."
}