CVE-2026-56213: Capgo Authorization Bypass in upsert_version_meta (CVSS 5.3)

Technical summary

CVE-2026-56213 is an authorization bypass in Capgo's public.upsert_version_meta SQL function, which is configured with the SECURITY DEFINER attribute and exposed as a Remote Procedure Call (RPC) endpoint via PostgREST. The function fails to validate whether the caller has permission to modify version_meta records for a given app_id. An attacker can invoke this RPC using the public anon key without authentication and inject arbitrary rows into the version_meta table for any application. The vulnerability permits data integrity violations but does not enable confidentiality breaches or availability attacks. CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N reflects network-accessible, low-complexity exploitation with no privileges or user interaction required, and localized integrity impact.

Business impact

Attackers exploiting this vulnerability can systematically corrupt version metadata across multiple applications, degrading operational visibility. Poisoned metrics may cause on-call teams to respond to phantom alerts, wasting incident response resources. Analytics dashboards will display unreliable data, impairing release decision-making and performance analysis. For organizations relying on Capgo for compliance or SLA reporting, corrupted version records could undermine audit trails and breach contractual obligations. The attack is persistent—false data remains until detected and manually corrected—amplifying the operational and reputational cost.

Affected systems

Capgo versions prior to 12.128.2 are affected. The vulnerability exists in the PostgREST-exposed RPC layer, meaning any Capgo instance with default or public API access is vulnerable if not patched. Self-hosted and managed Capgo deployments are equally at risk. The attack surface includes all applications managed within a vulnerable Capgo instance, regardless of their own configuration or security posture.

Exploitability

The vulnerability has a low barrier to exploitation. An attacker needs only network access to the Capgo API endpoint and knowledge of target app_ids, both of which are typically discoverable or public. No special tools, authentication credentials, or user interaction are required. The RPC call syntax is straightforward for anyone familiar with PostgREST conventions. The attack is repeatable and scalable—an attacker can poison metrics for dozens of applications in minutes. No patched versions have been added to the Known Exploited Vulnerabilities (KEV) catalog, though the simplicity of exploitation suggests a practical risk even without public proof-of-concept code.

Remediation

Upgrade Capgo to version 12.128.2 or later, which patches the authorization check in the upsert_version_meta function. Organizations should verify the patch version against Capgo's official release notes before deployment. During the patch window, consider restricting network access to the Capgo API endpoint via firewall rules or API gateway policies to limit exposure to trusted networks only. Review version_meta tables for suspicious entries inserted between the vulnerability disclosure date and patching; prioritize data cleanup for critical applications.

Patch guidance

Apply Capgo 12.128.2 or newer. Test the update in a staging environment first to confirm no breaking changes in dependent applications. If automatic updates are not available, follow Capgo's manual upgrade procedures as documented in their deployment guide. Verify the fix by confirming that the upsert_version_meta function now enforces ownership checks on app_id parameters. After patching, audit recent version_meta inserts for anomalies and consider resetting or validating metrics for applications that may have been targeted.

Detection guidance

Monitor PostgREST RPC logs for calls to public.upsert_version_meta from unauthenticated or unexpected sources. Look for unusual patterns of version_meta inserts with timestamps clustering around the vulnerability disclosure date (June 20, 2026) or later. Compare version records in dashboards against source-of-truth deployment logs; orphaned or unexplained version entries are a strong indicator. Alert on high-volume inserts into version_meta for a single app_id within short time windows. Review application version counts and timestamps for logical inconsistencies (e.g., hundreds of versions in minutes).

Why prioritize this

Although the CVSS score is MEDIUM (5.3), the practical severity warrants prompt patching. The vulnerability requires no authentication, is network-accessible, and can be reliably exploited at scale. The integrity impact directly undermines operational decision-making and audit integrity. Organizations dependent on Capgo for release management and monitoring should prioritize this patch within their standard update cycle, ideally within 1–2 weeks of availability, especially if the instance is exposed to untrusted networks.

Risk score, explained

The CVSS 3.1 score of 5.3 (MEDIUM) reflects a network-accessible vulnerability with low attack complexity, no privilege requirement, and no user interaction. The integrity impact is classified as low because the attack is localized to metadata and does not corrupt application code or cause service unavailability. However, the practical severity is elevated by the ease of exploitation, repeatability, and the persistence of poisoned data. Organizations should consider threat modeling around their specific use of version metrics—if release decisions or compliance reporting depend heavily on Capgo dashboards, the business risk may exceed the numeric CVSS score.

Frequently asked questions