CVE-2026-56319: Capgo App ID Enumeration via Differential Error Responses

Technical summary

The GET /statistics/app/:app_id endpoint in Capgo fails to consistently mask access control failures from unauthorized API keys. When an app-limited key requests statistics for an app outside its scope, the server returns a 500 PGRST116 error (database permission denied). For nonexistent app IDs, it returns a 401 error. This differential response allows an authenticated attacker to enumerate valid app IDs through trial and error, violating tenant isolation and information hiding principles (CWE-203).

Business impact

Multi-tenant SaaS environments rely on strict API scope enforcement to prevent cross-customer data discovery. This vulnerability creates a reconnaissance attack vector: a customer or third party with API credentials can map the application landscape of competitors or other tenants, potentially informing targeted attacks or competitive espionage. The breach is limited to enumeration—not data exfiltration—but reputational and compliance risk exists, especially for regulated deployments.

Affected systems

Capgo versions prior to 12.128.2 are affected. Specifically, the GET /statistics/app/:app_id endpoint is vulnerable when accessed by API keys restricted to a subset of apps. The vulnerability does not affect administrative or unrestricted API keys, nor does it impact the Capgo Cloud service if it has already been patched.

Exploitability

Exploitation is straightforward and requires only valid API credentials with limited app scope—a common configuration in multi-tenant setups. An attacker simply iterates through potential app IDs and observes response codes. No special tools, race conditions, or user interaction are needed. The attack is entirely passive from the target's perspective and leaves minimal forensic traces. CVSS 4.3 (Medium) reflects low impact (information disclosure only) and low attack complexity.

Remediation

Upgrade Capgo to version 12.128.2 or later. The patch normalizes error responses so that both inaccessible and nonexistent app IDs return the same HTTP status code and response body, eliminating the enumeration vector. Verify the upgrade is applied to all Capgo instances, including self-hosted deployments.

Patch guidance

1. Review your Capgo deployment version in configuration or logs. 2. Back up your Capgo database and configuration. 3. Follow Capgo's standard upgrade procedure to reach 12.128.2 or later (consult vendor release notes for your deployment method). 4. Test the patched endpoint with API keys having restricted scope to confirm error responses are now consistent. 5. Monitor for any integration disruptions post-upgrade and roll back if necessary, though this vulnerability fix is expected to be transparent to legitimate users.

Detection guidance

Review API access logs for the GET /statistics/app/:app_id endpoint. Look for patterns of requests from a single API key or user across many different app IDs, followed by a mix of 401 and 500 responses. Spike in 401 responses from a restricted-scope key may indicate enumeration attempts. Implement rate limiting on this endpoint if not already in place. Alert on high-frequency requests to nonexistent or cross-scope app IDs from the same API key within a short time window.

Why prioritize this

Although the CVSS score is Medium (4.3), the vulnerability sits at the intersection of common (multi-tenant SaaS) and sensitive (tenant isolation). In regulated industries or for vendors handling many distinct customer accounts, the ability to enumerate sibling tenants could trigger compliance violations (e.g., GDPR cross-tenant data discovery). Patch within 4–8 weeks as part of routine hardening, or sooner if you operate a public SaaS platform or handle sensitive customer data.

Risk score, explained

CVSS 4.3 is driven by: AV:N (network-accessible endpoint), AC:L (no special conditions), PR:L (requires valid API credentials), UI:N (no user interaction), S:U (no scope escalation), C:L (partial confidentiality loss via enumeration), I:N (no integrity impact), A:N (no availability impact). The score reflects that the attack requires pre-existing authentication and yields only metadata disclosure, not data exfiltration or service disruption.

Frequently asked questions