Capgo EUVD-2026-87718

Requires an authenticated account that already holds admin rights (check_min_rights('admin')) in the TARGET organization, plus direct access to the Supabase PostgREST endpoint exposing public.org_users. Given that admin, no invitation, no accept_invitation token, and no action by the target user are needed - the attacker directly INSERTs or UPDATEs an org_users row to promote any existing public.users account to active admin. What LIMITS exploitation: the PR:L admin precondition (a non-admin or outsider cannot perform the initial write) and that accounts being added must already exist in public.users. All versions are affected and no patch existed at publication, so no version constraint limits it.

This is a genuine authorization flaw (CWE-863) but a moderate real-world priority, not the near-critical event the vendor's 8.7 CVSS 4.0 score implies. The vendor vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) already encodes PR:L, so exploitation requires an already-authenticated organization ADMIN - the actor starts with substantial legitimate authority over the same organization. The VC:H/VI:H/VA:H claims are generous: the admin cannot read anything they could not already access (they administer the org), so the true novel impact is integrity of the membership graph - silently promoting arbitrary existing accounts to active org admins - not high confidentiality or availability loss. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis, so there is no evidence of active or automatable exploitation. The one signal that raises concern is that ALL versions are affected with no patch available at publication, and the bug is trivially reachable via a direct PostgREST write once admin is held. Net: a real, verifiable privilege-management weakness worth fixing, but bounded by the PR:L precondition and the absence of any exploitation telemetry - closer to medium than critical.

An authenticated user who already holds admin rights in a Capgo organization sends a direct Supabase PostgREST INSERT to public.org_users, adding an arbitrary existing public.users account as an active member with user_right="admin". Because the RLS policies only verify check_min_rights('admin') and never require a tmp_users invitation, an accepted invite token, or the RBAC anti-escalation checks, the target account gains full admin read/write over the organization and its apps without ever being invited. No public exploit code is identified, but the vendor confirms this behavior was reproduced in testing.