Capgo CVE-2026-56244

Exploitation requires a valid non-admin Capgo API key (PR:L) and network reachability to the Supabase REST endpoint of a Capgo instance running a version before 12.128.2 with the default row-level security policies on the webhooks table; no user interaction, no admin role, and no special configuration on the victim side are needed beyond having webhook receivers configured. Limiting factors: the attacker must already hold a non-admin API key (so fully external unauthenticated attackers are out of scope), and the integrity payoff only materializes for tenants that actually configure webhook receivers - instances with no webhook consumers leak a secret of no practical use.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L) accurately reflects the real risk: network-reachable, low-complexity, authenticated-with-a-non-admin-key, no user interaction, with high confidentiality impact on the leaked secret and low integrity impact via forged webhooks. There is no KEV listing and no public PoC, and EPSS is not provided - the realistic threat is targeted abuse by existing tenants or stolen low-privilege API keys rather than mass exploitation. The asymmetry worth flagging is that the integrity impact (VI:L) is arguably understated, because forged webhooks can drive downstream business logic in receivers; defenders should treat this as a trust-boundary break, not just a data leak.

An attacker who has obtained any non-admin Capgo API key - for example a key scoped to a single app, a leaked CI token, or a malicious tenant on a shared deployment - issues a Supabase REST query against the webhooks table and reads back the signing secret. They then craft an arbitrary webhook payload, compute a valid X-Capgo-Signature HMAC with the stolen secret, and POST it to the customer's configured webhook receiver, which trusts it as a legitimate Capgo event and triggers downstream actions such as deployment, billing, or notification logic.