CVE-2026-88862

Capgo (capgo.app) backend through 12.242.4 fails to validate parent-child delegation when processing the x-limited-key-id header, an improper authorization flaw (CWE-863) that lets an authenticated low-privilege API key act as a more privileged key owned by the same user without knowing its secret. When the header is supplied, checkKeyByIdPg() resolves the attacker-chosen numeric key ID using only the ID, its expiration state, and the authenticating key's user_id; hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding, and validateSubkeyUser() only compares owning user IDs, so setSubkeyAuthContext replaces the authenticated principal and effective API-key secret with the sibling key's. Because Capgo treats each API key as an independent RBAC principal with its own role binding, an attacker holding an apikey_manager key with no application access can exercise an app_admin sibling's permissions, such as managing or pushing live updates to the account's apps. Anyone running the Capgo backend at versions through 12.242.4 where multiple same-owner API keys exist is affected. No exploitation, public proof-of-concept, or KEV listing is known, and no patched version was available at the time of the advisory.

What to do: No fixed release was available at advisory time; monitor the Capgo changelog/GitHub and upgrade to the first release published after 12.242.4 as soon as it appears. Until then, treat any apikey_manager key as if it were app_admin: issue such keys only to fully trusted parties and consider rotating or revoking low-privilege keys distributed to agents or CI. Check backend logs for requests carrying x-limited-key-id whose resolved key had a different role than the authenticating key, as this indicates potential exploitation.