Description

Capgo (capgo.app) blocks direct user inserts into the public.manifest table with a RESTRICTIVE row-level security policy, but that restriction can be bypassed indirectly. A principal holding an app-scoped upload/write/all API key (upload+ rights) or an authenticated user with write+ rights on an app can update public.app_versions.manifest on a version whose storage_provider is 'r2-direct', which is not covered by the bundle content-lock check. The on_version_update async worker trusts record.manifest and, using the service-role Supabase client, inserts the attacker-controlled file_name, file_hash, and s3_path into public.manifest before clearing app_versions.manifest. When a channel points to the crafted version, the /updates endpoint returns the service-role-created manifest entry as a client-facing download_url, enabling OTA manifest poisoning through a trusted async worker path. All versions are affected; no patch was available at the time of publication.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-26T14:16:42.740Z",
  "pubdate": "2026-09-26T14:16:42.740Z",
  "executiveSummary": "Capgo is susceptible to an OTA (Over-The-Air) manifest poisoning vulnerability caused by an insecure trust relationship between user-controlled database records and an elevated-privilege asynchronous worker.\nThe vulnerability allows an authenticated attacker possessing app-scoped write or upload permissions to bypass Row-Level Security (RLS) constraints on the public.manifest table.\nBy manipulating the public.app_versions.manifest field within a version configured with the 'r2-direct' storage provider, an attacker can trigger the on_version_update async worker to perform unauthorized data insertion.\nThe worker, operating with service-role credentials, performs an insert into the public.manifest table using attacker-supplied data without adequate validation or sanitization.\nThis resulting poison manifest entry is subsequently served by the /updates endpoint to end-user clients, effectively serving malicious or arbitrary payloads as trusted application updates.\nThe exploit facilitates a supply chain compromise of the OTA update mechanism, allowing for unauthorized code execution on client devices running the targeted applications.\nAll Capgo versions are affected as the logic flaw resides in the architectural trust model between the user-facing database schema and the background synchronization processes.",
  "technicalDetails": "The root cause of this vulnerability lies in an architectural disconnect between the RLS policies enforced on direct client interactions and the implicit trust afforded to the backend on_version_update async worker.\nWhile the public.manifest table is protected by RLS to prevent direct user inserts, the system fails to validate the integrity of the manifest content when it is sourced from the public.app_versions.manifest column.\nThe exploitation process begins when an attacker with sufficient API permissions (upload+ or write+ rights) interacts with the public.app_versions table. The attacker targets a version entry where the storage_provider is set to 'r2-direct'.\nBecause 'r2-direct' versions are explicitly excluded from the standard bundle content-lock security checks, the attacker can successfully update the manifest field within public.app_versions to contain malicious metadata, including crafted file_name, file_hash, and s3_path parameters.\nOnce this record is updated, the application triggers the on_version_update asynchronous worker. This worker acts as a privileged entity using the service-role Supabase client, which bypasses existing RLS policies defined for end users.\nThe worker extracts the attacker-provided content from the record and performs a database insertion into the public.manifest table. Critically, the worker fails to sanitize or verify that the incoming data corresponds to a legitimate, signed, or previously audited bundle.\nAfter the insertion is complete, the worker clears the triggering field in public.app_versions.manifest, obfuscating the manipulation path.\nThe final stage of the attack occurs when an end-user client requests an update via the /updates endpoint. The service retrieves the poisoned manifest record from public.manifest, which the attacker has now populated with arbitrary data.\nThe system generates a download_url pointing to the attacker-controlled s3_path. The client, trusting the update channel, proceeds to fetch and execute the payload defined by the poisoned manifest.\nThis flow effectively elevates the attacker's low-privilege API access to a system-wide persistent compromise of the update delivery pipeline, bypassing all application-level integrity checks that were intended to govern the manifest lifecycle."
}