CVE-2026-88862: Capgo API Key Manager Authentication Bypass via x-limited-key-id
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/honomiddleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's userid, 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 apikeymanager 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 appadmin 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.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this?
The attacker needs an authenticated API key with the apikey_manager capability. They also need the numeric ID of a more privileged API key owned by the same user; they do not need that target key's secret.
Can this be used to impersonate keys belonging to other users?
The described validation compares owning user IDs, so the target key must belong to the same user as the authenticating key. The issue allows escalation between separate API-key principals and role bindings under that owner.
Which versions are known to be affected, and is a fix available?
The backend is described as affected through version 12.242.4, and the issue was reproduced on release 12.242.4. At the time of the advisory, no patched version was available.