CVE-2026-88862 in Capgo
Summary
by MITRE • 09/10/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Capgo backend versions through 12.242.4 represents a critical authorization bypass rooted in flawed parent-child delegation logic within the API key authentication middleware. The core technical flaw resides in how the system processes the x-limited-key-id header during request validation. Specifically, the checkKeyByIdPg function resolves an attacker-supplied numeric API key identifier by examining only its expiration status and the user_id associated with the authenticating key. This approach fails to enforce strict hierarchical constraints between the presenting credential and the target credential. The hasLimitedRbacSubkeyScope function further exacerbates this issue by accepting any key that possesses a non-organization, such as app-scoped, RBAC binding without verifying deeper structural relationships or ownership hierarchies beyond basic user ID matching. Consequently, the system treats API keys as independent principals with isolated role bindings rather than enforcing a strict chain of trust where child keys are strictly subordinate to their parent in terms of privilege escalation paths.
This architectural weakness allows an authenticated apikey_manager key that lacks direct application access privileges to manipulate the authentication context by supplying the numeric identifier of a more privileged sibling key owned by the same user. Through the setSubkeyAuthContext mechanism, the middleware replaces the effective API-key secret and principal with those of the targeted higher-privilege key. This enables an attacker possessing only low-level management permissions to exercise app_admin level privileges without ever knowing or submitting the actual secret for that elevated role. The attack effectively bypasses access control mechanisms by exploiting the assumption that same-owner keys share a valid delegation relationship, ignoring the necessity of explicit permission inheritance checks between specific parent and child roles.
The operational impact of this vulnerability is severe, as it allows unauthorized privilege escalation within the Capgo environment. An attacker with minimal initial access can gain full administrative control over applications associated with their user account. This compromises data integrity, confidentiality, and availability for all resources protected by those application-scoped keys. The issue was reproduced on release 12.242.4 following commit b3d02cdbc23ac59990785acacd1f113c07458568, which occurred after the remediation of GHSA-8h52-44r7-w343. At the time of the advisory publication, no patched version was available for immediate deployment, leaving systems exposed to exploitation until a formal fix is released and applied.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management due to the failure to enforce proper authorization levels during role transition. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, specifically the sub-technique of using legitimate credentials to bypass security controls by leveraging trusted relationships incorrectly implemented in the application logic. The flaw demonstrates a classic case of insecure direct object references combined with broken access control where identity verification is decoupled from privilege validation.
Mitigation strategies must focus on enforcing strict hierarchical checks within the middleware layer. Developers should implement explicit parent-child relationship validations that verify not only user ownership but also the specific RBAC hierarchy and permission inheritance rules between keys. The hasLimitedRbacSubkeyScope function requires revision to reject any delegation attempts where the target key does not explicitly inherit permissions from the presenting key or its ancestors. Additionally, implementing least-privilege principles for apikey_manager roles would limit the blast radius if such a bypass is attempted in future versions. Until patches are applied, organizations should monitor for anomalous privilege escalation patterns and restrict access to sensitive endpoints that rely on this specific header-based authentication flow.