CVE-2026-88862: Cap-go capgo.app · Incorrect Authorization
Affects Cap-go capgo.appSource CVE Database V5
Not known to be exploited · CVSS 8.7 High.
Data as of 10/25/2026, 16:58:58 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 10 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wild: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Cap-gocapgo.app | Affected
| Fixed in– |
AI-suggested
At the time of the advisory, no patched version was available. Users should monitor the vendor's official channels for updates and apply patches once released. Until then, restrict issuance and use of apikey_manager keys to trusted parties only and consider additional access controls to limit potential abuse.
Description
Capgo (capgo.app) backend through 12.242.4 does not validate parent-child delegation when processing the x-limited-key-id header. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, while hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding and validateSubkeyUser() only compares owning user IDs. Because Capgo treats API keys as independent RBAC principals with separate role bindings, an authenticated apikey_manager API key with no application access can supply the numeric ID of a more privileged same-owner key and have the middleware replace the authenticated principal and effective API-key secret with that key (setSubkeyAuthContext), exercising an app_admin sibling's permissions without knowing or submitting its secret. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568) after the fix for GHSA-8h52-44r7-w343; at the time of the advisory no patched version was available.
Impact
An attacker with an authenticated apikey_manager key can escalate privileges by impersonating a more privileged sibling API key owned by the same user. This allows unauthorized access to application administration capabilities without needing the secret of the privileged key, potentially leading to unauthorized actions within the application environment.
Summary
Capgo backend versions up to 12.242.4 have a flaw in the authorization logic related to API key delegation. The function checkKeyByIdPg() resolves API keys based on key ID, expiration, and user ID but does not verify proper delegation hierarchy. Because API keys are treated as independent RBAC principals, an authenticated apikey_manager key lacking application access can supply the numeric ID of a more privileged key owned by the same user. This causes the middleware to replace the authenticated principal and effective API key secret with that of the privileged key, allowing unauthorized use of app_admin permissions without the secret. The vulnerability was confirmed on version 12.242.4 after a previous fix (GHSA-8h52-44r7-w343), and no patch was available at the time of the advisory.