Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain or steal valid apikey_manager API key
-
DeliveryEnumerate numeric ID of privileged app_admin sibling key
-
ExploitCraft API request with x-limited-key-id header set to target key ID
-
ExecutionMiddleware resolves key by user_id match, skips delegation check
-
PersistsetSubkeyAuthContext replaces session principal with app_admin key
-
ImpactExecute privileged app management operations
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to possess a valid (non-revoked, non-expired) |
| Impact | 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 |
| Exploit ScenarioDerived | An attacker who has compromised or stolen an |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 10, 2026
Privilege escalation in the Capgo (capgo.app) backend through version 12.242.4 allows an authenticated API key holder to impersonate a more privileged sibling key by supplying its numeric ID in the x-limited-key-id header, bypassing the intended parent-child delegation hierarchy entirely. The middleware's checkKeyByIdPg() resolves the caller-supplied key ID using only the ID, expiration state, and owning user_id, while validateSubkeyUser() only checks that both keys share an owner - neither function verifies that the resolved key is an actual descendant of the authenticating key. An apikey_manager key can therefore silently acquire app_admin permissions via setSubkeyAuthContext without knowledge of the target key's secret; the issue was confirmed on release 12.242.4 after a prior incomplete fix (GHSA-8h52-44r7-w343), and no patched version was available at time of advisory.
RemediationAI
No vendor-released patch was identified at time of analysis - the advisory explicitly states that no patched version was available at disclosure. Organizations using Capgo should actively monitor the GitHub security advisory at https://github.com/Cap-go/capgo.app/security/advisories/GHSA-5hjr-xhx8-x5j7 and the VulnCheck advisory at https://www.vulncheck.com/advisories/capgo-api-key-manager-authentication-bypass-via-x-limited-key-id for a remediated release. As immediate compensating controls, operators should audit and revoke all apikey_manager API keys that are not strictly required, since exploitation depends on the attacker holding such a key; this reduces the attack surface at the cost of breaking any automation relying on delegation. Avoid issuing apikey_manager keys to CI/CD pipelines or external integrations that do not explicitly require delegation. Self-hosted operators can apply a code-level patch to hono_middleware.ts that enforces a true parent-child relationship check before setSubkeyAuthContext is invoked - the fix for GHSA-8h52-44r7-w343 provides a prior reference point but was insufficient, so the delegation graph must be explicitly validated. Disabling or blocking the x-limited-key-id header at the reverse-proxy layer is an aggressive but effective compensating control, with the trade-off that all legitimate subdelegation flows will be broken.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Capgo is a cloud backend for Capacitor (Ionic) mobile app over-the-air (OTA) update delivery, built on Supabase edge functions using the Hono framework. The vulnerable code resides in supabase/functions/_backend/utils/hono_middleware.ts. The platform implements a hierarchical API key system where keys carry RBAC role bindings (e.g., apikey_manager, app_admin, organization-level scopes). The x-limited-key-id header is designed to allow a parent key to delegate authority to a child (sub)key. The root cause (CWE-863, Incorrect Authorization) is that checkKeyByIdPg() resolves the attacker-supplied key by numeric ID and owner user_id alone, hasLimitedRbacSubkeyScope() only requires a non-organization scope on the resolved key, and validateSubkeyUser() only compares owning user IDs - none of the three functions verify that the resolved key is a true child or delegate of the authenticating key. Because Capgo treats all API keys as independent RBAC principals, a low-privilege key can silently replace itself as the session principal with any same-owner key through setSubkeyAuthContext. The affected CPE is cpe:2.3:a:cap-go:capgo.app:*:*:*:*:*:*:*:*.
Know when Cap Go gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Network-exploitable authorization bypass requiring a low-privilege API key (PR:L); no scope change as impact is confined to the exploiting account's Capgo resources.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, 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 apikey_manager 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 app_admin 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.
Technical POC Analysis
CWE-863 (Incorrect Authorization): the API-key middleware authorizes a key substitution by ownership and target scope, never by delegation from the authenticating principal.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Capgo backend's API key authentication contains a privilege escalation vulnerability (CVSS 8.7) enabling lower-privileged API key holders to silently assume admin permissions; no public exploit identified at time of analysis. Organizations deploying applications through Capgo face risk of unauthorized application modification or deployment if API credentials are compromised. No patch is currently available from the vendor.
Implement immediate key rotation and regenerate credentials with minimal required scopes. Configure IP-based access restrictions on Capgo API endpoints where supported. Enable comprehensive audit logging for all API authentication and permission-related activities. Segregate Capgo API access to dedicated automation accounts and monitor for suspicious permission escalation attempts. Restrict internal system access to Capgo APIs through network segmentation.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Affected Products (CPE)CVE.org
Account pre-registration hijack in Capgo before 12.128.2 lets a remote unauthenticated attacker claim an account under a
Improper access control in Capgo (capgo.app) lets any holder of an ordinary full API key forge a trusted SSO provider by
Authentication bypass in Capgo prior to version 12.128.2 lets attackers defeat email-based OTP verification by tampering
Authorization bypass in Capgo (capgo.app), a live-update/OTA platform for Capacitor mobile apps, allows a de-provisioned
Cross-tenant data poisoning in Supabase Capgo before 12.128.2 allows remote unauthenticated attackers to corrupt billing
Unauthenticated denial of service in Cap-go capgo (capgo-backend) before 12.128.12 allows remote attackers to exhaust Po
Unauthenticated retrieval of deleted over-the-air update bundles from capgo.app through version 12.129.0 is possible via
Capgo's direct exposure of the public.org_users table through Supabase PostgREST lets an authenticated user who already
Authenticated principals who hold an app-scoped upload/write/all API key with upload+ rights - or any user granted write
Cross-tenant metadata modification in Capgo before 12.244.1 allows an authenticated attacker to alter image object metad
Privilege escalation in Capgo (capgo.app) before 12.267.1 allows a principal holding the apikey_manager role to rotate a
Authenticated administrators on Capgo (capgo.app) can grant channel-scoped permissions to non-member users because the p
EUVD-2026-75412
GHSA-92q7-3qv3-754g
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB