CVE-2026-56232: Capgo Authentication Bypass Vulnerability

CVE-2026-56232 Overview

Capgo versions prior to 12.128.2 contain an authorization flaw in the middlewareKey function. The implementation fails to enforce the limited_to_orgs and limited_to_apps constraints on subkeys supplied through the x-limited-key-id header. An authenticated attacker can reference one of their own subkeys in the header, causing downstream route handlers to fall back to the unrestricted parent API key. This effectively bypasses the scope restrictions intended to confine subkey access to specific organizations or applications. The flaw is tracked under CWE-863: Incorrect Authorization.

Critical Impact
Attackers with valid low-privilege subkeys can escalate access to the parent key's full scope, gaining unauthorized read and write access across organizations and applications managed by Capgo.

Affected Products

Capgo self-hosted and managed deployments prior to version 12.128.2
Any Capgo API consumer relying on subkey scoping via x-limited-key-id
Downstream route handlers that inherit the parent key context from middlewareKey

Discovery Timeline

2026-06-24 - CVE-2026-56232 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-56232

Vulnerability Analysis

Capgo issues parent API keys and allows users to derive subkeys scoped to specific organizations (limited_to_orgs) or applications (limited_to_apps). The middlewareKey function is responsible for resolving the inbound API key, checking the x-limited-key-id header, and binding the resolved subkey context to subsequent handlers.

The vulnerability arises because the middleware does not validate the scope constraints attached to the referenced subkey before authorizing the request. When a request includes a valid x-limited-key-id referencing a subkey owned by the caller, the middleware accepts the subkey identifier but proceeds with the unrestricted parent key for downstream authorization decisions. Route handlers therefore evaluate permissions against the parent key's broader scope, not the subkey's restricted scope.

Exploitation requires only low-privilege authenticated access. The attacker uses their legitimately issued subkey, but the bypass grants them access equivalent to the parent key holder. Confidentiality, integrity, and availability of resources managed through the API are all impacted.

Root Cause

The root cause is missing authorization enforcement in middlewareKey. The function reads the subkey identifier but never compares the request's target organization or application against the limited_to_orgs and limited_to_apps arrays stored on the subkey record. Authorization defaults to the parent key context, violating the principle of least privilege.

Attack Vector

The attack is network-reachable and requires authentication with a valid Capgo API key. An attacker crafts an HTTP request that includes their own subkey identifier in the x-limited-key-id header while targeting resources outside the subkey's intended scope. Because the middleware does not reject the mismatch, the request is processed under the parent key's authority. See the GitHub Security Advisory GHSA-2h89-vcvx-5pvh and the VulnCheck advisory for the technical write-up.

Detection Methods for CVE-2026-56232

Indicators of Compromise

Requests containing the x-limited-key-id header that target organizations or applications not listed in the referenced subkey's limited_to_orgs or limited_to_apps fields
API access patterns where a subkey is used to reach resources historically only touched by the parent key
Spikes in cross-organization or cross-application API activity originating from a single subkey identifier

Detection Strategies

Audit Capgo API access logs and correlate the x-limited-key-id value with the resource path or organization parameter to identify scope mismatches
Compare subkey metadata in the Capgo database against historical request scopes to flag subkeys that accessed resources outside their declared limits
Deploy WAF or API gateway rules that inspect the x-limited-key-id header and reject requests whose target resource is not in the subkey's allowed list

Monitoring Recommendations

Enable verbose logging on the middlewareKey execution path to record both the resolved parent key and the referenced subkey for every request
Alert on any authenticated request that mutates resources in an organization the subkey is not authorized to access
Continuously review API key inventory and rotate any subkey that exhibits anomalous cross-scope activity

How to Mitigate CVE-2026-56232

Immediate Actions Required

Upgrade Capgo to version 12.128.2 or later on all self-hosted and managed instances
Rotate parent API keys that may have been exposed through subkeys belonging to untrusted users
Review audit logs for the period preceding the patch to identify any unauthorized cross-scope access
Temporarily disable issuance of new subkeys for high-value parent keys until the upgrade is verified

Patch Information

The fix is included in Capgo 12.128.2. The patched middlewareKey enforces limited_to_orgs and limited_to_apps constraints against the request target before granting access. Refer to the GitHub Security Advisory GHSA-2h89-vcvx-5pvh for the patch commit and upgrade instructions.

Workarounds

Block or strip the x-limited-key-id header at an upstream reverse proxy until the upgrade is applied
Restrict the issuance of subkeys to trusted internal users only, limiting the population of accounts able to abuse the bypass
Apply an API gateway policy that validates the x-limited-key-id header against the request's organization and application parameters

bash

# Example NGINX directive to strip the vulnerable header at the edge
location /api/ {
    proxy_set_header x-limited-key-id "";
    proxy_pass http://capgo_backend;
}