Capgo’s access‑control enforcement is incomplete for bundle versions marked r2‑direct. Because the enforcement logic skips rows whose previous storage provider was r2‑direct, critical fields such as name, app_id, session_key, key_id, storage_provider, r2_path, external_url, checksum, manifest, and native_packages can be altered after the bundle is uploaded. An attacker who can write or upload bundles can leverage this flaw to tamper with bundle metadata, potentially redirecting devices to malicious or non‑intended content. This bypasses the hardening that was previously introduced to ensure app_version metadata immutability.

All versions of Cap‑go, the Cap‑go web platform managing app bundles. The issue exists in the database schema (supabase/schemas/prod.sql) and the backend update endpoint (supabase/functions/_backend/utils/pg.ts). No specific version numbers are provided; the vulnerability is present across the reported product line.

The CVSS score of 5.3 indicates moderate severity. No EPSS value is available, and the vulnerability is not listed in CISA’s KEV catalog. The attack requires possession of a Cap‑go API key that has bundle write or upload permissions, which is a privilege often granted only to trusted developers. The flaw allows the attacker to alter bundle metadata via direct PostgREST requests, and the modified metadata will be served to devices through the standard /updates endpoint. Because the flaw exists in the content‑lock checks and channel/version join logic, no additional infrastructure or advanced exploits are needed to achieve the attack, but it is confined to accounts that already hold the necessary API permissions.