CVE-2026-56248: Capgo Unauthenticated Denial-of-Service via Audit Logs RLS Policy

Technical summary

The vulnerability arises from a Row-Level Security (RLS) policy implementation in Capgo's audit_logs table that is exposed via the Supabase PostgREST API. The PostgreSQL query planner executes expensive filtering logic before the RLS policy can reject unauthorized access, allowing unauthenticated requests using the public anon key to trigger statement timeouts (PostgREST error 57014). The expensive query execution exhausts database connection pools and CPU resources; under concurrent load, this resource exhaustion propagates to unrelated API endpoints (such as /orgs), causing HTTP 500 errors and application-wide service degradation. The flaw is classified as a CWE-400 (Uncontrolled Resource Consumption) issue.

Business impact

This vulnerability enables a straightforward denial-of-service attack that requires no authentication or specialized tools. An attacker can render the Capgo application unavailable to legitimate users by sending repeated requests from a single machine or distributed sources. The cascading failure pattern means that even endpoints unrelated to audit logs become unavailable, amplifying the blast radius. For organizations relying on Capgo for mobile app deployment and lifecycle management, this translates to inability to deploy updates, manage app versions, or serve legitimate API requests during an active attack. Recovery requires database intervention or application restart.

Affected systems

Capgo (capgo-backend) versions prior to 12.128.12 are vulnerable. The issue specifically affects deployments using Supabase as the database backend with PostgREST API exposure. Any organization running an affected version with internet-facing PostgREST endpoints is at risk, regardless of deployment environment (cloud or self-hosted). The public anon key is sufficient to trigger the vulnerability; no privileged credentials are required.

Exploitability

Exploitability is very high. The attack requires only network access and knowledge of the audit_logs endpoint URL—both of which are readily discoverable. No authentication is needed; the public anon key functions by design. No complex exploitation techniques or race conditions are required; simple sequential or concurrent HTTP requests suffice to trigger timeout conditions and resource exhaustion. Proof of concept would be trivial (a basic curl loop or load-testing tool). This is a network-accessible, unauthenticated denial-of-service vulnerability with a low barrier to execution.

Remediation

Upgrade Capgo to version 12.128.12 or later. This version addresses the RLS policy execution flaw by restructuring the query planning or policy enforcement to prevent expensive operations from executing before authentication checks. Organizations unable to upgrade immediately should consider restricting network access to the PostgREST API using a Web Application Firewall (WAF) or API gateway, limiting requests to the audit_logs endpoint, or temporarily disabling public anon access if business logic permits. Database-level rate limiting may also mitigate repeated timeout requests.

Patch guidance

Apply Capgo version 12.128.12 or later as soon as feasible, given the high exploitability and lack of exploit complexity. Verify the patch version against the vendor's official release notes before deployment. The upgrade should be tested in a staging environment to confirm that audit_logs functionality and related RLS policies operate correctly post-patch. Monitor database query performance after patching to ensure the RLS execution cost has been resolved. If the application is managed by a SaaS provider (e.g., Capgo Cloud), check whether the provider has already deployed the patch to your tenant.

Detection guidance

Monitor PostgreSQL slow query logs and application error logs for frequent PostgREST error 57014 (statement timeout) entries originating from the public.audit_logs endpoint. Spike in HTTP 500 errors across multiple endpoints, particularly when correlated with audit_logs queries, suggests an active attack or vulnerability exploitation. Set up alerts on database connection pool exhaustion and CPU utilization spikes coinciding with POST/GET requests to the audit_logs endpoint. Analyze access logs for repeated unauthenticated requests to the audit_logs endpoint from the same source IP or user agent. Implement distributed tracing to map the cascading failures from audit_logs queries to downstream service degradation.

Why prioritize this

This vulnerability scores CVSS 7.5 (HIGH) and combines high exploitability, no authentication requirement, network accessibility, and significant availability impact. The cascading failure pattern increases operational risk. While not yet in the CISA KEV catalog, the low exploitation barrier and immediate business impact warrant urgent patching. Organizations should treat this as a priority vulnerability requiring action within days rather than weeks, especially if the application is internet-facing or handles time-sensitive deployments.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a network-accessible, unauthenticated attack vector (AV:N/PR:N) with low complexity (AC:L), no impact on confidentiality or integrity, but high impact on availability (A:H). The score does not account for the cascading failure pattern or the business-critical nature of app deployment infrastructure, which may warrant organizational risk elevation. The unchanged scope (S:U) indicates the impact is contained to the vulnerable component's resources, though the cascading effects blur this boundary in practice.

Frequently asked questions