HIGH 7.5

CVE-2026-56082: Capgo Authentication Bypass Enables Billing Record Tampering

Capgo, a build management platform, has a serious access control flaw in a database function that should only work for authenticated users but is accidentally exposed to anonymous users. An attacker with just the public API key can forge billing records, overwrite existing build logs for other companies, and artificially inflate billable time—essentially gaining the ability to sabotage another organization's usage data and financial records without needing any credentials or authentication.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Weaknesses (CWE)
CWE-284
Affected products
0 configuration(s)
Published / Modified
2026-06-19 / 2026-06-22

NVD description (verbatim)

Capgo (Cap-go/capgo) before 12.128.2 contains an improper access control vulnerability in the SECURITY DEFINER PostgREST RPC function public.record_build_time, which is granted to the anon role and callable with only the public Supabase publishable (sb_publishable_*) anon key. An unauthenticated attacker can insert rows into public.build_logs for arbitrary organizations and, because the function uses ON CONFLICT (build_id, org_id) DO UPDATE, can overwrite existing usage/billing records by reusing the same build_id for a target org. This enables cross-tenant tampering of billing build logs and financial-impact denial of service by inflating billable build time.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-56082 is an improper access control vulnerability in Capgo versions before 12.128.2. The public.record_build_time PostgREST RPC function is marked as SECURITY DEFINER but is incorrectly granted to the anon role, making it callable via the public Supabase publishable key (sb_publishable_*). The function accepts an org_id parameter and uses ON CONFLICT (build_id, org_id) DO UPDATE to insert or upsert rows in public.build_logs. By reusing a known build_id, an unauthenticated attacker can overwrite existing billing records for arbitrary organizations, manipulating billable build time and creating financial denial of service.

Business impact

Organizations relying on Capgo for build tracking and billing could face disrupted financial reporting, inflated or corrupted billing records, and loss of trust in usage data integrity. Attackers could artificially increase billable time for competitors or customers, causing incorrect billing cycles, chargeback disputes, and operational confusion. If billing is tied to these logs, the attack directly affects revenue accuracy and customer trust. Multi-tenant deployments are particularly at risk since one compromised org can corrupt logs for many others.

Affected systems

Capgo versions prior to 12.128.2 are vulnerable. The vulnerability exists at the database layer in the PostgREST RPC interface and affects any Capgo deployment where the anon role is permitted to call the public.record_build_time function. Organizations using Capgo for build management and billing on affected versions should be considered at risk if the public API key is obtainable (which, by design, it is).

Exploitability

Exploitability is high. No authentication is required—an attacker only needs knowledge of the public Supabase publishable key (which is intentionally public) and valid build_id and org_id pairs. The attack requires only network access and can be executed via simple HTTP requests or database calls. There are no barriers to repeated exploitation. The CVSS score of 7.5 (High) reflects network-accessible, unauthenticated access with no user interaction and direct impact to integrity.

Remediation

Upgrade Capgo to version 12.128.2 or later. The patch should restrict the public.record_build_time function access so that only authenticated users (with appropriate role-based permissions) can call it, removing the grant to the anon role. Organizations must verify that the function is no longer callable via public API keys and test that legitimate build logging still functions correctly after patching.

Patch guidance

Apply version 12.128.2 or later of Capgo. Verify against the vendor's official release notes and advisory that the patch removes anon role access to the public.record_build_time function. Test in a staging environment to confirm that build recording continues to work for authenticated clients while rejecting unauthenticated requests. Monitor logs post-deployment for any failed build_time recording attempts that might indicate incomplete rollout or application misconfiguration.

Detection guidance

Search for unauthorized calls to the public.record_build_time function from unauthenticated sources (requests using only the public/anon key without a user session). Monitor for bulk inserts or updates to public.build_logs with mismatched or suspicious org_id values. Look for patterns of repeated build_id reuse across different organizations, especially with inflated build_time values. Review PostgREST access logs for high-frequency RPC calls from external IPs targeting this function. Correlate anomalies in build_logs with unusual billing spikes or usage discrepancies.

Why prioritize this

This vulnerability should be prioritized for immediate patching. It is unauthenticated, requires no user interaction, has direct integrity impact on billing records, and enables cross-tenant attacks. The financial and operational consequences are severe, particularly for SaaS platforms where billing accuracy is critical. Although not currently on the KEV catalog, the ease of exploitation and business impact warrant urgent remediation.

Risk score, explained

The CVSS 3.1 score of 7.5 (High) accurately reflects an unauthenticated network-accessible attack (AV:N, PR:N, UI:N) with high integrity impact (I:H) on billing and usage records, but no confidentiality or availability impact in the strict sense. The score does not fully capture the financial denial of service and cross-tenant trust violation, which elevate practical risk above the numeric score.

Frequently asked questions

Can this vulnerability be exploited without knowing an organization's org_id?

Likely not easily. An attacker would need to discover or enumerate valid org_id values. However, if org_ids are sequential, predictable, or disclosed in public logs, discovery is trivial. Even if enumeration is required, the unauthenticated nature of the attack means it can be done at scale without detection.

Does patching to 12.128.2 automatically fix corrupted billing records?

No. The patch prevents future unauthorized modifications, but it does not audit or repair billing logs that have already been tampered with. Organizations should review their build_logs for suspicious entries dating back to when the vulnerability was introduced and validate billing records against independent sources.

If Capgo is self-hosted, am I still vulnerable?

Yes, if your self-hosted instance runs Capgo version 12.128.2 or earlier and exposes the PostgREST API with the anon role granted to public.record_build_time. Verify your Capgo version and apply the patch regardless of deployment model.

How can we detect if this vulnerability has been exploited against us?

Search your PostgREST or database logs for calls to public.record_build_time from API requests authenticated only with the public (anon) key. Cross-reference the org_ids and build_ids in those calls against your expected organizations. Unexpected org_ids or spike patterns in build_time values suggest tampering. Audit your billing records for discrepancies and reconcile against payment events or customer reports.

This analysis is based on the published CVE description and CVSS assessment. Specific patch availability, version numbers, and deployment details should be verified against Capgo's official security advisory and release notes. Testing should be performed in a staging environment before production deployment. Organizations should conduct independent audits of their billing records if they suspect exploitation. SEC.co does not warrant the completeness or applicability of this guidance to any specific environment. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).