Description

Capgo (capgo.app) contains an incomplete access-control/content-lock enforcement issue affecting all versions; no patch is available at the time of publication. The `enforce_encrypted_bundle_trigger` / `check_encrypted_bundle_on_insert` content lock in supabase/schemas/prod.sql exempts `app_versions` rows whose previous `storage_provider` is `r2-direct`, so delivery-critical columns (name, app_id, session_key, key_id, storage_provider, r2_path, external_url, checksum, manifest, native_packages) remain mutable while a row is in that state. Separately, the channel/version join used by the `/updates` endpoint (supabase/functions/_backend/utils/pg.ts) filters only deleted versions and does not exclude `r2-direct` versions, so such rows remain OTA-selectable. An attacker holding a Capgo API key with bundle write/upload permission can create or keep a bundle version in the `r2-direct` state, assign it to a channel, and then modify these fields via direct PostgREST requests, causing altered bundle metadata (for example checksum and session_key) to be served to devices through `/updates`. This bypasses the post-upload content immutability hardening added for a previous app_versions metadata-tampering issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-26T14:16:43.017Z",
  "pubdate": "2026-09-26T14:16:43.017Z",
  "executiveSummary": "Capgo (capgo.app) is affected by an incomplete access-control and content-lock enforcement vulnerability across all versions. The vulnerability stems from a logical flaw in the database schema constraints that fail to enforce immutability for specific bundle metadata states. This allows authenticated users with bundle write or upload permissions to modify critical delivery fields for OTA bundles.\nThe vulnerability involves an improper exemption within the 'enforce_encrypted_bundle_trigger' and 'check_encrypted_bundle_on_insert' functions in 'supabase/schemas/prod.sql'. Versions utilizing the 'r2-direct' storage provider are excluded from content-lock enforcement, rendering delivery-critical metadata mutable. Because the '/updates' endpoint (implemented in 'supabase/functions/_backend/utils/pg.ts') fails to exclude these 'r2-direct' versions, tampered metadata can be served directly to client devices.\nThe risk implication is significant, as an attacker with an API key possessing write access can facilitate supply-chain compromise by altering bundle checksums, session keys, or external URLs. This effectively bypasses previous hardening efforts intended to prevent metadata tampering. The vulnerability is currently unpatched, posing a risk to the integrity of OTA updates delivered to end-user applications.",
  "technicalDetails": "The root cause of this vulnerability lies in an insufficient database-level access control logic that permits the modification of sensitive 'app_versions' rows based on their 'storage_provider' state. In 'supabase/schemas/prod.sql', the triggers 'enforce_encrypted_bundle_trigger' and 'check_encrypted_bundle_on_insert' are designed to maintain content immutability after a bundle has been committed. However, these triggers explicitly exempt rows where 'storage_provider' is set to 'r2-direct'.\nThis design flaw results in the metadata fields 'name', 'app_id', 'session_key', 'key_id', 'storage_provider', 'r2_path', 'external_url', 'checksum', 'manifest', and 'native_packages' remaining mutable while in the 'r2-direct' state. The security breach is compounded by the implementation of the '/updates' endpoint in 'supabase/functions/_backend/utils/pg.ts'. The join logic used by this function to identify the latest version for a channel only filters based on deletion status, failing to exclude 'r2-direct' versions. Consequently, a compromised or malicious bundle version—or a legitimate version that has been tampered with post-upload—remains eligible for OTA distribution.\nAn attacker with a valid API key capable of performing bundle write/upload operations can exploit this by ensuring an 'app_version' remains in the 'r2-direct' state. By issuing direct PostgREST requests, the attacker can manipulate the delivery metadata. The attack flow involves: 1) Initializing or identifying an 'app_version' record with 'storage_provider' set to 'r2-direct'. 2) Associating this version with an active deployment channel. 3) Utilizing authorized API access to perform direct updates to the sensitive metadata fields listed above. 4) The '/updates' endpoint, when queried by client devices, retrieves the tampered metadata record because it lacks a filter for the 'r2-direct' state. 5) Client applications subsequently receive and execute the altered bundle metadata, such as a modified 'checksum' or 'external_url', potentially leading to the delivery of unauthorized or malicious code updates, thereby bypassing previously implemented integrity hardening."
}