CVE-2026-56230: Capgo Broken Authorization – Cross-Tenant API Key Impersonation

Technical summary

The vulnerability is a broken object-level authorization (BOLA) flaw in the middlewareKey() middleware. The middleware accepts the x-limited-key-id HTTP header from client requests but fails to validate that the authenticated user is the rightful owner of the specified limited key. Because the validation is missing, an authenticated attacker can supply another tenant's key ID in the header, causing the middleware to grant authorization as if they possessed that key. This bypasses authorization checks across multiple API endpoints, effectively allowing cross-tenant resource access. The flaw maps to CWE-639 (Authorization Bypass Through User-Controlled Key).

Business impact

This vulnerability enables account takeover and data exfiltration across multiple tenant accounts on a shared Capgo instance. An attacker with valid credentials to one tenant can laterally move to access, modify, or exfiltrate sensitive data belonging to other tenants without their knowledge. For SaaS deployments or multi-tenant environments, this represents a critical breach of data isolation. Regulatory implications include potential violations of data residency and separation requirements under GDPR, HIPAA, or SOC 2 Type II controls.

Affected systems

Capgo versions prior to 12.128.2 are affected. The vulnerability requires an authenticated user account (PR:L in the CVSS vector), meaning it does not affect completely unauthenticated users but does affect any legitimate or compromised account. Multi-tenant Capgo deployments are at highest risk because the flaw enables cross-tenant access.

Exploitability

Exploitation is straightforward for any authenticated user. The attack requires only network access (AV:N), no special conditions (AC:L), and no user interaction (UI:N). An attacker simply needs to craft HTTP requests with a target tenant's key ID in the x-limited-key-id header. The barrier to entry is low: possession of any valid Capgo account. No exploit code or special tooling is required—basic HTTP manipulation suffices. The lack of KEV designation does not reduce the practical exploitability; it reflects only that the vulnerability has not yet been added to CISA's Known Exploited Vulnerabilities catalog.

Remediation

Upgrade Capgo to version 12.128.2 or later immediately. This version includes validation logic in middlewareKey() that verifies the authenticated user's ownership of the supplied limited key before granting authorization. Organizations running multi-tenant Capgo instances should prioritize this patch to restore proper tenant isolation.

Patch guidance

Apply version 12.128.2 or any subsequent release. Before patching, verify your current Capgo version and test the patch in a non-production environment to ensure compatibility with your API integrations. Review your deployment documentation for upgrade procedures specific to your installation method (Docker, package manager, or source build). After patching, conduct a brief functional test of key-based API authentication to confirm the fix does not break legitimate access patterns.

Detection guidance

Look for anomalous x-limited-key-id header values in API logs—specifically, cases where the authenticated user ID does not match the tenant ownership of the supplied key ID. Monitor for cross-tenant API requests originating from a single user account, particularly requests accessing resources outside that user's expected tenant scope. Enable detailed request logging in Capgo if available, capturing both the authenticated user context and the supplied header values. Correlate login events with subsequent unusual API activity to identify compromised accounts being exploited for lateral movement.

Why prioritize this

This is a HIGH-severity vulnerability (CVSS 8.8) affecting tenant isolation in multi-tenant systems. It requires only authentication (not exploitation of a zero-day or unauthenticated path), but the impact is severe: confidentiality, integrity, and availability are all compromised across tenant boundaries. The fix is available and non-disruptive. Organizations running Capgo in multi-tenant mode should treat this as a P1 security issue; single-tenant deployments face lower risk but should still patch promptly.

Risk score, explained

The CVSS 3.1 score of 8.8 reflects the combination of network-accessible attack surface (AV:N), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), and high impact across all three security attributes (C:H, I:H, A:H). The score is not higher than 9.0+ because the attack requires valid authentication (PR:L) rather than being unauthenticated, and because the scope remains unchanged (S:U)—the attacker accesses their own tenant's resources using misappropriated keys, not escalating to system-level compromise. Nonetheless, HIGH severity and an 8.8 score demand immediate action.

Frequently asked questions