Executive brief
Capgo's API key management system allows an authenticated user with limited permissions to impersonate a more privileged API key belonging to the same account by simply providing its numeric ID in a request header. An attacker with a basic "apikey manager" role can escalate to administrator-level access and perform any action the higher-privileged key allows—such as modifying applications or channels—without needing the actual password or secret of that privileged key. This completely bypasses Capgo's intended access controls and could allow account takeover or data manipulation.
Technical details
This is an improper authorization vulnerability (CWE-863) in Capgo's middleware authentication layer. The checkKeyByIdPg() function in hono_middleware.ts resolves API keys using only the numeric ID, expiration state, and user_id—without validating any parent-child delegation relationship or permission containment. When a user supplies an x-limited-key-id header, hasLimitedRbacSubkeyScope() accepts any key with a non-organization RBAC binding, and validateSubkeyUser() only verifies both keys share the same owner. The middleware then calls setSubkeyAuthContext() to replace the authenticated principal and active secret with the target key. An attacker with an authenticated apikey_manager role (which normally has no application access) can thus supply the numeric ID of a privileged sibling app_admin key and exercise its permissions. The attack requires an existing authenticated API key and network access; no patch was available at time of advisory publication.
Affected products
- Cap-go Capgo backend through 12.242.4
Timeline
- 2026-09-10: disclosed: Public disclosure via GitHub Security Advisory
- 2026-08-27: other: Security advisory GHSA-5hjr-xhx8-x5j7 published