EUVD-2026-42248
GHSA-fw56-3v5m-f44w
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remote, unauthenticated (public anon key), no user interaction; read-only PII/org disclosure gives C:H with no integrity or availability impact and unchanged scope.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
2DescriptionCVE.org
Capgo (Cap-go/capgo) before 12.128.2 exposes the Supabase PostgREST RPC function public.get_orgs_v6(userid uuid), which is SECURITY DEFINER and granted to the anon role, allowing unauthenticated access. Because the function accepts a caller-supplied user UUID without verifying it matches the authenticated user, an attacker using only the public publishable API key can query POST /rest/v1/rpc/get_orgs_v6 with an arbitrary user UUID to retrieve that user's organization membership, roles, subscription/trial metadata, and management_email (PII).
AnalysisAI
Broken access control in Capgo (the Capacitor live-update/OTA platform) before 12.128.2 lets any unauthenticated caller holding only the public publishable API key read arbitrary users' organization data. The Supabase PostgREST RPC function public.get_orgs_v6 runs as SECURITY DEFINER and is granted to the anon role, yet trusts a caller-supplied user UUID instead of the authenticated identity, exposing org membership, roles, subscription/trial metadata, and the management_email PII. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but exploitation is trivial and requires no credentials beyond the intentionally-public key.
Technical ContextAI
Capgo is a self-hostable/SaaS backend for delivering over-the-air updates to Capacitor mobile apps, built on Supabase (PostgreSQL + PostgREST). PostgREST exposes database functions as HTTP RPC endpoints; a function declared SECURITY DEFINER executes with the privileges of its owner rather than the caller, deliberately bypassing row-level security. The root cause (CWE-200, Exposure of Sensitive Information) is really a missing authorization check inside such a definer function: get_orgs_v6(userid uuid) accepts an arbitrary UUID argument and returns that user's data without comparing it to auth.uid() (the authenticated JWT subject). Because EXECUTE was additionally granted to the anon role, even the unauthenticated publishable/anon key - which is meant to be shipped in client apps - is sufficient to call POST /rest/v1/rpc/get_orgs_v6. This is a classic Supabase misconfiguration pattern (SECURITY DEFINER + anon grant + no internal identity check), functionally an IDOR (CWE-639) surfaced as information disclosure.
RemediationAI
Vendor-released patch: upgrade to Capgo 12.128.2 or later, which corrects the function's authorization handling. If you cannot upgrade immediately, apply compensating database-level controls: REVOKE EXECUTE on public.get_orgs_v6(uuid) FROM anon (and from authenticated if broader access is not required), which closes unauthenticated access at the cost of breaking any legitimate client flow that relies on the RPC; and/or modify the function to enforce the caller identity by adding a check that the userid argument equals auth.uid() (or auth.jwt()), rejecting mismatches - the correct long-term fix that preserves intended functionality. As an edge mitigation you can restrict or filter POST /rest/v1/rpc/get_orgs_v6 at a reverse proxy/WAF, though this is brittle and may block legitimate app traffic. Self-hosters should rotate exposure assumptions but note the publishable/anon key itself does not need rotation since it is public by design. Follow guidance in GHSA-m7mm-35v3-82f4 and the VulnCheck advisory linked above.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today