Capgo Backend EUVD-2026-75412

Exploitation requires the attacker to possess a valid (non-revoked, non-expired) apikey_manager API key for the targeted Capgo account - this is a low-privilege authenticated condition (PR:L) and fully unauthenticated exploitation is not possible. The attacker must additionally know or enumerate the numeric ID of a more privileged sibling API key (e.g., app_admin) belonging to the same account owner; the advisory does not confirm whether these IDs are sequential or otherwise easily guessable, but numeric enumeration is a realistic vector. Both keys must share the same user_id, meaning cross-account escalation is not possible via this path. Organization-scoped keys are excluded by hasLimitedRbacSubkeyScope(), so the privilege ceiling reachable through this bypass is app-scoped roles such as app_admin. The backend must be running version 12.242.4 or earlier. Limiting factors: the attacker cannot exploit this unauthenticated, cannot cross account boundaries, and cannot reach organization-level roles through this specific bypass.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) correctly captures the network-accessible, low-complexity character of this authorization bypass requiring only a low-privilege credential. The primary threat is intra-account horizontal privilege escalation: any holder of an apikey_manager key - including a compromised CI/CD pipeline token or a malicious insider - can silently gain full application management capabilities without knowledge of the target key's secret. No EPSS score is present in the input data, so exploitation probability cannot be precisely quantified, and the vulnerability is not listed in CISA KEV; however, the low attack complexity and the existence of a detailed public GitHub security advisory (GHSA-5hjr-xhx8-x5j7) make it readily weaponizable once a low-privilege key is obtained. The fact that this bypass survived a prior remediation attempt signals a subtle, persistent design flaw rather than a simple coding error - even a mid-sized municipal IT team in kielce managing Capacitor-based mobile apps through Capgo should treat this as urgent given the lack of any available patch. Real-world risk is bounded by the requirement to first hold a valid apikey_manager key, which limits the exposure to insider threats, credential theft, and supply-chain compromise scenarios rather than fully unauthenticated attack paths.

An attacker who has compromised or stolen an apikey_manager API key for a Capgo account issues an API request to the Capgo backend, setting the x-limited-key-id header to the numeric ID of a same-owner app_admin sibling key - these IDs may be enumerable via API or predictable. The middleware resolves the target key (matching on user_id only), skips parent-child validation, and replaces the session principal with the privileged key via setSubkeyAuthContext, granting full application management access without the attacker ever possessing or submitting the app_admin key's secret. No public exploit code has been identified at time of analysis, but the mechanism is fully described in the public security advisory.