CVE-2026-56230: Capgo Auth Bypass Vulnerability

CVE-2026-56230 Overview

CVE-2026-56230 is a Broken Object Level Authorization (BOLA) vulnerability in Capgo versions prior to 12.128.2. The flaw resides in the middlewareKey() function, which accepts the client-controlled x-limited-key-id HTTP header without validating ownership. Authenticated users can supply another tenant's limited key ID to bypass authorization checks. This grants access to cross-tenant resources across multiple API endpoints. The weakness is categorized under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Authenticated attackers can access, modify, or exfiltrate resources belonging to other tenants by supplying a target tenant's limited key ID in an HTTP header.

Affected Products

Capgo versions prior to 12.128.2
Multi-tenant API endpoints relying on middlewareKey() for authorization
Self-hosted and managed Capgo deployments

Discovery Timeline

2026-06-30 - CVE-2026-56230 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-56230

Vulnerability Analysis

Capgo's middlewareKey() function processes the x-limited-key-id HTTP header supplied by the client. The function retrieves the referenced limited key but does not verify that the authenticated caller owns that key. As a result, any authenticated user can present a limited key ID belonging to a different tenant. Downstream API handlers then trust the resolved key context and grant access to resources scoped to the victim tenant. The vulnerability affects multiple endpoints that rely on this middleware for tenant boundary enforcement.

Root Cause

The root cause is missing object-level ownership validation in the authorization middleware. The application treats a client-supplied identifier as an authoritative binding to a tenant context. It does not cross-check the identifier against the authenticated principal's session or account. This design pattern is a textbook Broken Object Level Authorization flaw, tracked as CWE-639.

Attack Vector

Exploitation requires network access to the Capgo API and a low-privileged authenticated account. The attacker enumerates or obtains a valid x-limited-key-id value for a target tenant. The attacker then issues API requests with that header value while authenticating as themselves. The server resolves the header to the victim's key and executes the request under the victim's tenant context. See the GitHub Security Advisory and the VulnCheck Advisory on CAPGO for further technical detail.

Detection Methods for CVE-2026-56230

Indicators of Compromise

API requests containing the x-limited-key-id header where the referenced key does not match the authenticated principal's tenant
Sudden spikes in cross-tenant data access from a single authenticated user account
Unexpected read or write operations on resources belonging to tenants that the requesting account has no legitimate relationship with

Detection Strategies

Log and inspect the x-limited-key-id header on all inbound API requests, correlating its value with the authenticated user's tenant
Alert when the tenant resolved from the header differs from the tenant tied to the session or bearer token
Review historical access logs for header-based tenant mismatches predating the patch

Monitoring Recommendations

Aggregate API access logs and enrich with authenticated user, tenant ID, and header-supplied key ID fields
Baseline per-account request volume and flag statistical outliers touching multiple tenant contexts
Monitor for reconnaissance behavior such as sequential or enumerated x-limited-key-id values

How to Mitigate CVE-2026-56230

Immediate Actions Required

Upgrade Capgo to version 12.128.2 or later without delay
Rotate all limited keys issued before the upgrade to invalidate any values an attacker may have harvested
Audit API access logs for prior use of x-limited-key-id values that do not match the caller's tenant

Patch Information

The maintainers addressed the flaw in Capgo 12.128.2. The fix enforces ownership validation in middlewareKey() so that a supplied x-limited-key-id is accepted only when it belongs to the authenticated user. Refer to the GitHub Security Advisory for the exact commits and release notes.

Workarounds

If immediate patching is not possible, add a gateway or reverse proxy rule that strips or validates the x-limited-key-id header before it reaches the Capgo backend
Temporarily disable API endpoints that depend on middlewareKey() until the upgrade is deployed
Restrict API access to trusted networks and enforce short-lived credentials to limit the exploitation window

bash

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