CVE-2026-56235: Cap-go Unauthenticated Authorization Bypass Exposes Cross-Tenant Metrics

Technical summary

The vulnerability stems from improper authorization checks in Cap-go's Supabase PostgREST RPC function layer. Three metric-reporting functions are granted to the anon (unauthenticated) role without validating that the caller's organization matches the queried org_id parameter. Because Supabase's public API key (sb_publishable_*) is intentionally distributed in client applications, any network client can invoke these functions with arbitrary org_id values. The functions return detailed telemetry arrays when a valid org_id is queried and empty arrays for invalid ones, creating an oracle for org enumeration. No authentication token or private key is required.

Business impact

Cross-tenant telemetry leakage enables competitive intelligence gathering and reconnaissance. Attackers can profile organization sizes, growth rates, and feature adoption by monitoring metrics over time. Enumeration of app IDs and org existence checks facilitate targeted attacks against specific customers. For Cap-go's platform, this undermines SaaS security isolation guarantees and may trigger breach notification or compliance reporting obligations if customer usage patterns are considered sensitive data under regulations like GDPR.

Affected systems

Cap-go versions before 12.128.2 are affected. The vulnerability is specific to Cap-go's Supabase-backed telemetry endpoints and affects all deployments relying on these metric RPC functions, including self-hosted instances using the same backend schema and API configuration.

Exploitability

Exploitability is straightforward. An attacker requires only the public API key (which appears in Cap-go client-side code), network access to Cap-go's Supabase instance, and knowledge that metric functions exist. No authentication, privilege escalation, or user interaction is required. Automated enumeration of all valid org IDs and metric queries is trivial, making large-scale reconnaissance practical.

Remediation

Upgrade to Cap-go version 12.128.2 or later, which should implement proper authorization checks verifying that the caller's org membership or permission level matches the queried org_id. Verify that patch release notes explicitly confirm the addition of these checks. For defense-in-depth, review Supabase RLS (Row Level Security) policies to ensure metric tables enforce org isolation at the database level, independent of application logic.

Patch guidance

Apply the Cap-go 12.128.2 update immediately, as the fix directly addresses the authorization bypass. Confirm the update is deployed across all production and staging environments. After patching, test that unauthenticated or cross-org requests to metric endpoints are rejected. Review your Supabase audit logs for the publication date (2026-06-20) forward to identify whether unauthorized metric queries occurred; cross-reference accessed org_ids against your customer roster.

Detection guidance

In Supabase audit logs, search for calls to get_app_metrics, get_global_metrics, or get_total_metrics from the anon role or without an authenticated user context. Identify requests with org_id parameters that do not match the request origin or JWT claims. Implement alerting on metric function calls with mismatched org_id and authentication identity. Check Cap-go application logs for metric queries with suspicious org_id patterns (e.g., sequential enumeration, requests from external IPs).

Why prioritize this

Although the CVSS score is medium (5.3), the vulnerability should be prioritized as high operational risk because it enables direct, unauthenticated access to business-sensitive telemetry across all organizations on the platform. The reconnaissance capability—org existence detection, app enumeration, and usage profiling—poses significant customer trust and competitive harm. Exploitation requires no sophistication and leaves minimal forensic traces. Affected organizations should patch within 48 hours.

Risk score, explained

CVSS 5.3 reflects a network-accessible information disclosure with no authentication requirement and low complexity (AV:N/AC:L/PR:N). Severity is capped at medium because the vulnerability does not enable data modification, availability impact, or privilege escalation. However, the practical risk is elevated by the breadth of affected data (all orgs), ease of exploitation, and competitive sensitivity of the leaked telemetry. The absence of KEV listing (as of the modification date) does not reduce risk—this may reflect low current exploit prevalence rather than low severity.

Frequently asked questions