Capgo CVE-2026-56319

Exploitation requires possession of a valid app-limited Capgo API key - the attack is not possible without authenticated API access (PR:L per CVSS 4.0 vector). The oracle is specific to app-limited keys: such keys receive PGRST116 errors for out-of-scope apps rather than a uniform 401, which is the behavior that leaks app existence. The attacker must be able to reach the Capgo API over the network (AV:N). What limits exploitation: only app ID existence is revealed, not app content, credentials, or user data; the attacker must already be a Capgo platform participant with a legitimately or illicitly obtained API key; and enumeration is constrained to platforms where app IDs follow a guessable or iterable format.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) accurately characterizes this as a low-complexity, network-reachable flaw with constrained impact. The PR:L metric is the primary mitigating factor: exploitation is gated behind possession of a valid, scoped Capgo API key, limiting the attacker population to legitimate platform users, former employees, or parties who have obtained a leaked key. The confidentiality impact (VC:L) is bounded to app ID enumeration - not app data, credentials, or user records - making this a reconnaissance-grade finding rather than a direct data breach. Neither CISA KEV listing nor public POC code is present in the available intelligence, and no EPSS score was supplied, so there is no signal of active or widespread exploitation. Real-world priority should be elevated in multi-tenant SaaS contexts where knowledge of competitor or sibling app IDs enables targeted follow-on attacks, but for most deployments this is a medium-priority patch rather than an emergency response item.

An attacker with a valid app-limited Capgo API key iterates through numeric or UUID-format app ID candidates against GET /statistics/app/:app_id, recording whether each response is a 500 PGRST116 (app exists, access denied) or a 401 (app nonexistent). After cycling through a sufficient ID space, the attacker produces a verified map of real app IDs belonging to other tenants on the platform. No public exploit code has been identified at time of analysis, but the attack requires only standard HTTP tooling given the fully described oracle mechanism.