Capgo CVE-2026-100611

Exploitation requires an authenticated principal holding the apikey_manager organization role (permissions org.manage_apikeys and org.read) issuing POST /apikey with a valid JWT session against a Capgo capgo.app backend at version ≤12.261.0. No user interaction and no higher privilege is needed. The key limiting factor is that the attacker must already possess the apikey_manager role within the target organization - this is authenticated insider/delegated-role abuse, not remote-unauthenticated access. The flaw is present in default role seeding (apikey_manager priority_rank 78 exceeds deploy roles' ranks 68/66/58/57, and the deny-list omits app_developer, app_uploader, channel_developer, channel_uploader), so no non-default configuration is required to trigger it.

This is a genuine, well-described privilege-escalation flaw (CWE-269) whose real-world risk sits in the medium band. The vendor CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) correctly identifies it as network-reachable, low-complexity, and requiring only low privileges (PR:L) - the attacker must already hold the apikey_manager org role. There is NO EPSS score, NO CISA KEV listing, and NO public exploit code, so there is no evidence of active or imminent exploitation; the risk is a logic/authorization defect that a malicious or compromised low-privilege org member could abuse deliberately. One signal-to-note-conflict: the vendor scores subsequent-system impact as N (SC/SI/SA:N), yet the described outcome - minting a deploy-role key to push arbitrary OTA JavaScript to ALL end users of the organization's apps - is effectively a supply-chain compromise of downstream end-user devices, which I read as a scope/subsequent-system integrity impact the vendor vector understates. The mitigating reality is that this is an insider/authenticated-role abuse (not remote-unauth), which bounds the exploitation population, but the blast radius (all app end users) is severe, and no patched version exists, so it warrants prompt attention for anyone running self-hosted or SaaS Capgo with delegated apikey_manager roles.

A user granted only the apikey_manager role (intended to manage API keys, not deploy code) authenticates with a JWT and calls POST /apikey requesting a key bound to a deploy role such as app_uploader or channel_developer. Because the deny-list omits those roles and apikey_manager's priority_rank (78) outranks them, the request succeeds; the attacker then uses the resulting key to publish a malicious OTA JavaScript bundle that is delivered to every end user of the organization's apps. No public exploit code is identified at time of analysis, but the attack requires no special tooling beyond an authenticated API call.