CVE-2026-100619: Capgo OTA Manifest Poisoning via app_versions.manifest Bypass
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.appversions.manifest on a version whose storageprovider is 'r2-direct', which is not covered by the bundle content-lock check. The onversionupdate async worker trusts record.manifest and, using the service-role Supabase client, inserts the attacker-controlled filename, filehash, and s3path into public.manifest before clearing appversions.manifest. When a channel points to the crafted version, the /updates endpoint returns the service-role-created manifest entry as a client-facing downloadurl, enabling OTA manifest poisoning through a trusted async worker path. All versions are affected; no patch was available at the time of publication.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs an app-scoped API key with upload, write, or all privileges, or an authenticated user account with write-or-higher rights on an app. The vulnerable update must target a version whose storage_provider is set to r2-direct.
Does this require direct access to the manifest table?
No. Direct inserts into public.manifest are restricted, but an attacker can supply manifest data through public.app_versions.manifest and rely on the asynchronous version-update worker to create the manifest entry with service-role privileges.
What is the practical impact if a crafted version is assigned to a channel?
The /updates endpoint can return the attacker-controlled manifest entry with a client-facing download_url. This enables poisoning of OTA update manifests for clients receiving updates from that channel.
Are any versions or configurations known to be unaffected?
All versions are affected according to the advisory. The described exploitation path specifically depends on an r2-direct version and credentials or user permissions with write-level access or greater.
What can be done while no patch is available?
Restrict and rotate app-scoped API keys with upload, write, or all privileges, and limit authenticated write access to apps. Review r2-direct versions and channel assignments for unexpected manifest-related changes or versions that could expose untrusted update content.