Cap Go
Monthly
Improper authorization in Capgo App before 12.128.12 allows an authenticated organization member to mint a non-expiring, app-scoped API key even when the owning organization has enabled require_apikey_expiration and configured a max_apikey_expiration_days limit. The POST /apikey handler resolves the target app from the supplied app_id but omits the owning organization from the list passed to validateExpirationAgainstOrgPolicies when org_id, limited_to_orgs, and expires_at are absent, so the validation returns early and the expiration policy is silently skipped. Exploitation requires a valid org account with permission to create app-scoped keys and an organization that actually has the policy configured; the only privilege gained is indefinite key lifetime, and no public exploit code was identified at time of analysis. The vendor fixed the issue in version 12.128.12.
Capgo's Supabase backend bundle-promotion API allows an authenticated API key holder with app-level channel.promote_bundle to bypass explicit per-channel deny overrides and promote a bundle to a channel they were denied, updating public.channels.version. This affects Capgo (Cap-go/capgo.app) deployments, confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and likely earlier versions; no vendor-released patch was known at publication. The flaw only has impact when an administrator has configured a per-channel allow or deny override on the target channel_id, and no public exploit identified at time of analysis; the vendor/VulnCheck CVSS 4.0 base score is 7.2.
Capgo's native build TUS upload proxy forwards a user-controlled TUS resource suffix to the builder service while injecting Capgo's own privileged builder API key, without ever binding that suffix to the upload_path or upload_session_key of the build job the caller was actually authorized for, allowing cross-job writes to another build's upload resource. All versions of capgo.app are affected, and no vendor patch was available at the time of the advisory publication. Exploitation is access-gated rather than anonymous: it requires a valid Capgo API key of scope 'all' or 'write' carrying app.build_native permission for at least one application (plus a legitimate proxy path from an active job A), and knowledge of another job's (job B's) TUS resource suffix, so the realistic impact is integrity-only - corruption of build artifacts - with no read/exfiltration or availability loss, and no public exploit code has been identified at time of analysis.
Capgo's direct exposure of the public.org_users table through Supabase PostgREST lets an authenticated user who already holds admin rights in an organization bypass the invitation and role-assignment workflow entirely, inserting or updating org_users rows to add any existing public.users account as an active member with user_right="admin". The vulnerable row-level security policies only enforce public.check_min_rights('admin', ...), so they skip the pending-invitation check in tmp_users, the /private/accept_invitation token flow, and the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. Per this assessment the practical impact is a moderate authorization flaw (PR:L, C:L/I:H/A:N) rather than a near-critical event; all versions are affected, no public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (it is not in CISA KEV).
Unauthenticated retrieval of deleted over-the-air update bundles from capgo.app through version 12.129.0 is possible via the public file read endpoint, which fails to check an artifact's deletion status before serving it; a cache hit additionally triggers restoration of the deleted object back into R2 storage. Any party holding a previously issued cached bundle URL can read content the operator believed was deleted, and the secondary restoration side effect re-persists that content. Exploitation requires a valid, previously recorded cached URL for a since-deleted and cached bundle - attackers cannot mint access from nothing - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis. Risk is driven by the precondition of a leaked or harvested cache URL, the vendor (VulnCheck) rating this CVSS 4.0 8.7 with high confidentiality impact, while our own assessment scores it lower (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) because the dependent-on-a-valid-cached-URL and cached-then-deleted preconditions materially limit realistic exposure.
Authenticated principals who hold an app-scoped upload/write/all API key with upload+ rights - or any user granted write+ rights on a target app - can poison Capgo's OTA update manifest so that client devices receive attacker-controlled download URLs. The bypass works because the on_version_update async worker runs with the Supabase service-role client and implicitly trusts the manifest field of an app_versions row whose storage_provider is 'r2-direct', a configuration excluded from the bundle content-lock check; the worker then writes attacker-supplied file_name, file_hash and s3_path values into public.manifest, and once a channel points at the crafted version the /updates endpoint serves the injected record as a client-facing download_url. All versions are affected, no vendor patch was available at time of publication, and no public exploit code has been identified at time of analysis.
An authenticated holder of an app-limited write API key on Capgo (capgo.app) can abuse the PUT /app/:id endpoint's user-controlled `icon` field to make a privileged service-role worker rewrite a private storage object belonging to another tenant, such as an organization logo, that the API key cannot read or write directly under Supabase Storage RLS. The flaw is a cross-tenant authorization bypass (CWE-639 / confused deputy) rather than remote code execution: the attacker cannot read the targeted object, cannot supply arbitrary replacement content beyond the referenced object being re-uploaded with cleaned metadata, and must already possess a scoped write API key for at least one app on the instance. Our independent assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N and considers the vendor's 8.7 (PR:N) rating materially overstated; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated administrators on Capgo (capgo.app) can grant channel-scoped permissions to non-member users because the platform fails to validate that principals in channel_permission_overrides belong to the organization (CWE-862). Attackers with app or org admin privileges can insert override rows with arbitrary external user UUIDs, enabling those external users to exercise permissions such as channel.promote_bundle and push over-the-air bundles to a channel. Exploitation requires an existing admin account; no public exploit code has been identified at time of analysis, and the vendor's CVSS 4.0 score of 8.7 appears generous given the high privilege prerequisite and the limited confidentiality and integrity impact assessed as moderate priority.
Authenticated organization admins in capgo.app can corrupt the organization's Stripe billing pointer (customer_id) by sending a direct UPDATE to the Supabase PostgREST API, bypassing the official organization update endpoint that excludes this column. The flaw requires an org admin with org.update_settings but without org.update_billing, and only affects the attacker's own organization's plan/billing state, not broader system data. No vendor patch was available at the time of the advisory, and no public exploit code has been identified.
Privilege escalation in Capgo (capgo.app) before 12.267.1 allows a principal holding the apikey_manager role to rotate a higher-privileged same-owner sibling API key - such as an org_super_admin key - via the API key rotation PUT endpoint and retrieve the replacement plaintext secret, giving the attacker the credentials of the stronger principal. Exploitation is authenticated: the attacker must already possess or have compromised an apikey_manager key, and a more privileged sibling key under the same owner must exist, which limits exposure to organizations that delegate key-management duties to lower-trust roles. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; a vendor fix is available in 12.267.1.
Cross-tenant metadata modification in Capgo before 12.244.1 allows an authenticated attacker to alter image object metadata belonging to other tenants by exploiting a confused-deputy metadata-cleaning worker that fails to validate object-key ownership. The vulnerability requires knowledge of a victim tenant's image object key and the ability to update database rows containing image keys; it results in integrity impact only, with no confidentiality or availability impact, and no public exploit has been identified at time of analysis.
Vertical privilege escalation and account takeover in Capgo (capgo.app) through 12.261.0: an authenticated attacker who already holds the org_admin tier permission org.update_settings can rewrite the provider_id column of a public.sso_providers row over PostgREST and point the organization's email-domain trust anchor at an identity provider they control, after which the server-side SSO merge routine binds the attacker's identity to the legitimate org owner account, nulls that account's password, and deletes its other identities and sessions. The impact is full owner/super_admin takeover plus lockout of the real owner, although exploitation is gated on the target organization having an active SSO provider configured and on the attacker already possessing org_admin in that organization; no public exploit code was identified at time of analysis and there is no CISA KEV entry. The incomplete nature of the fix (a BEFORE UPDATE guard that freezes dns_verified_at, domain, status and enforce_sso but leaves provider_id, metadata_url and attribute_mapping writable under a table-wide ALL grant with only row-scoped RLS) makes this a durable privilege-escalation path rather than a one-off misconfiguration.
Privilege escalation in the Capgo capgo.app backend (versions ≤ 12.261.0) lets an authenticated user who holds only the apikey_manager organization role mint API keys bound to higher-privileged deploy roles (app_developer, app_uploader, channel_developer, channel_uploader). Those keys can in turn be used to push arbitrary over-the-air JavaScript updates to every end user of the organization's apps, giving an insider or delegated-role holder unauthorized write access to production app content. Exploitation requires a valid JWT session and the apikey_manager role (authenticated, no user interaction), no public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; at advisory publication no patched version was available.
Improper access control in Capgo (capgo.app) lets any holder of an ordinary full API key forge a trusted SSO provider by writing directly to the public.sso_providers table exposed via Supabase PostgREST, setting status='active' and enforce_sso=true without passing the backend provisioning route. This sidesteps the Enterprise-plan gate, Supabase Management API provider creation, DNS TXT domain-ownership verification, and the pending_verification→verified→active workflow, so an attacker can assert SSO enforcement for arbitrary unverified domains and disrupt normal login. All versions are affected, no patch was available at advisory time, and there is no public exploit identified at time of analysis beyond the VulnCheck write-up.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Privilege escalation in the Capgo (capgo.app) backend through version 12.242.4 allows an authenticated API key holder to impersonate a more privileged sibling key by supplying its numeric ID in the `x-limited-key-id` header, bypassing the intended parent-child delegation hierarchy entirely. The middleware's `checkKeyByIdPg()` resolves the caller-supplied key ID using only the ID, expiration state, and owning `user_id`, while `validateSubkeyUser()` only checks that both keys share an owner - neither function verifies that the resolved key is an actual descendant of the authenticating key. An `apikey_manager` key can therefore silently acquire `app_admin` permissions via `setSubkeyAuthContext` without knowledge of the target key's secret; the issue was confirmed on release 12.242.4 after a prior incomplete fix (GHSA-8h52-44r7-w343), and no patched version was available at time of advisory.
Capgo's MFA enforcement is defeated by an authentication assurance level (AAL) mismatch across two distinct code paths: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts Supabase JWTs without inspecting the aal claim, and the direct RBAC path (checkPermissionPg() calling public.rbac_check_permission_direct() in rbac.ts) authorizes operations by user ID alone, bypassing the assurance-level check that public.verify_mfa() correctly enforces. An attacker holding only the victim's account password can authenticate, receive an aal1 JWT, exercise privileged RBAC operations without triggering any MFA challenge, mint a persistent app_admin API key, and modify production OTA channel configurations - all of which survive logout of the original aal1 session. No patched version has been released; all versions of capgo.app are affected, and the advisory includes a validated proof-of-concept demonstrating bundle swap on a production channel.
Authorization bypass in Capgo (capgo.app), a live-update/OTA platform for Capacitor mobile apps, allows a de-provisioned user to retain channel-level permissions after their organization RBAC access has been revoked. Because Capgo does not clean up channel permission overrides when a user's last organization role binding is deleted, stale grants remain active - letting the former member perform privileged actions such as pushing or changing production OTA update versions. Reported by VulnCheck (GHSA-qfxq-2ch8-hjg9); no public exploit identified at time of analysis.
Unauthenticated organization enumeration in Capgo before 12.128.2 lets attackers abuse the Supabase PostgREST SECURITY DEFINER RPC public.rescind_invitation, which returns distinguishable NO_ORG versus NO_RIGHTS errors when invoked with only a publishable (anon) API key. This oracle lets remote unauthenticated attackers confirm which organization IDs exist, building a target list for follow-on phishing and social engineering. Reported by VulnCheck; no public exploit code and no CISA KEV listing at time of analysis.
Cross-tenant data poisoning in Supabase Capgo before 12.128.2 allows remote unauthenticated attackers to corrupt billing and quota records by invoking the SECURITY DEFINER record_build_time RPC with only a public anon API key. The flaw stems from missing authorization inside a privilege-elevated PostgREST function, enabling arbitrary build-time inserts against any organization. No public exploit identified at time of analysis, but the trivial network-reachable invocation pattern makes weaponization straightforward.
Unauthenticated denial of service in Cap-go capgo (capgo-backend) before 12.128.12 allows remote attackers to exhaust PostgreSQL resources by sending unfiltered queries to the public.audit_logs PostgREST endpoint using the public anon key. Because the query planner runs expensive logic before Row-Level Security rejection, repeated requests trigger statement timeouts (error 57014) and cascade into HTTP 500 failures on unrelated endpoints such as /orgs. No public exploit identified at time of analysis, though the technique is fully described in the GHSA advisory.
Privilege inversion in Cap-go (Capgo) before 12.128.2 lets holders of read-only API keys cancel running native builds by abusing the GET /build/logs/:jobId SSE endpoint. On client disconnect the server invokes cancelBuildOnDisconnect() using the privileged BUILDER_API_KEY, bypassing the app.build_native permission enforced on POST /build/cancel/:jobId. No public exploit identified at time of analysis, but the issue is trivially reproducible against any deployment exposing the log stream.
SQL injection in Capgo (cap-go) before 12.128.2 allows authenticated users with read-level API keys to access analytics data belonging to other tenants by injecting arbitrary SQL through multiple unparameterized parameters in cloudflare.ts. The flaw stems from direct string interpolation of request-body values into Cloudflare Analytics Engine queries, enabling cross-tenant data exposure. No public exploit identified at time of analysis, though a VulnCheck advisory and an upstream GitHub Security Advisory document the issue.
Cross-tenant billing log tampering in Capgo (Cap-go/capgo) before 12.128.2 allows unauthenticated attackers holding only the public Supabase publishable anon key to insert or overwrite build_logs rows for arbitrary organizations via the SECURITY DEFINER PostgREST RPC public.record_build_time. Because the function is granted to the anon role and uses ON CONFLICT (build_id, org_id) DO UPDATE, attackers can inflate or alter another tenant's billable build time, producing financial-impact denial of service. No public exploit identified at time of analysis, though the vendor advisory (GHSA-42xj-3h9w-26h5) and a VulnCheck write-up describe the attack path in detail.
Account pre-registration hijack in Capgo before 12.128.2 lets a remote unauthenticated attacker claim an account under a victim's email address before that email is verified, then lock the legitimate owner out by enabling two-factor authentication on the squatted account. The flaw stems from a CWE-640 weak password recovery / account-binding logic issue and carries a CVSS 4.0 score of 9.3; no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Authentication bypass in Capgo prior to version 12.128.2 lets attackers defeat email-based OTP verification by tampering with HTTP responses returned to the client, which the application trusts to decide whether verification succeeded. Successful exploitation enables fraudulent 2FA enrollment and account takeover, and no public exploit has been identified at time of analysis though VulnCheck has published an advisory describing the response-manipulation technique.
Denial of service in Capgo Console versions prior to 12.28.2 allows an authenticated attacker to lock legitimate users out of authentication and onboarding flows by triggering account deletion while a device identifier is bound to the active session. The platform incorrectly persists the deletion state against the device identifier rather than the account, causing the affected browser or device to be redirected to an account-disabled page for roughly 30 days. No public exploit identified at time of analysis, but a vendor patch and GHSA advisory (GHSA-qmrm-qgwr-55jf) have been published following disclosure by VulnCheck.
Account takeover in Cap-go (Capgo) versions prior to 12.128.2 allows an attacker holding a temporary authenticated session to change the account's registered email address without re-authentication (no password or MFA prompt), then trigger a password reset to attacker-controlled inbox and seize the account. The flaw, reported by VulnCheck and tracked as a missing-authentication weakness (CWE-306), has a vendor patch but no public exploit identified at time of analysis.
An insecure direct object reference in Capgo through 12.128.2 lets any authenticated tenant user read cross-tenant objects stored in the private images bucket by supplying attacker-controlled icon storage paths to the PUT /app/:appId endpoint, which then returns service-role-signed URLs valid for 7 days. Because the signed URLs bypass per-tenant authorization, exposed assets include user avatars, organization logos, and app icons. Exploitation requires a valid non-privileged Capgo account and yields only low-sensitivity read access; no modification or availability impact is possible, and no public exploit code was identified at time of analysis.
Authenticated users who hold the app.build_native permission for a given app in Capgo.app before 12.264.5 can keep writing to a native build upload session after its stored one-hour upload_expires_at has passed or after the build has moved beyond the upload phase, because the TUS proxy at /build/upload/:jobId enforces only the build_native permission and never checks upload expiry or build lifecycle state. The proxy loads just app_id, owner_org, builder_job_id and upload_path and then forwards POST, PATCH and HEAD requests to the internal builder, so stale or out-of-phase sessions remain writable. The weakness maps to CWE-613 (Insufficient Session Expiration) with low integrity and availability impact (CVSS v3.1 5.3, AV:N/AC:L/PR:L/UI:N), there is no public exploit identified at time of analysis, and the flaw can be neutralized entirely if the separate downstream builder service rejects the stale request on its own.
Incomplete content-lock enforcement in Capgo (capgo.app) lets an authenticated holder of an API key with bundle write/upload permission keep or create an app_versions row in the `r2-direct` storage_provider state and then mutate delivery-critical columns - including checksum, session_key, key_id, manifest, r2_path, external_url and native_packages - via direct PostgREST requests. Because the channel/version join used by the `/updates` endpoint filters only deleted versions and does not exclude `r2-direct` rows, the tampered bundle remains OTA-selectable and altered metadata is served to client devices. Exploitation is authenticated only (the assessed vector requires PR:L), is confined to bundles the key can already write, and yields metadata tampering over OTA rather than server-side code execution; all versions are affected and no vendor-released patch was identified at the time of analysis, with no public exploit identified at time of analysis.
Stale channel permission overrides in Capgo can let a former source-organization member repoint a destination-owned app channel after a cross-organization app transfer, causing the /updates endpoint to serve an attacker-selected OTA bundle to devices. The flaw affects all Capgo (capgo.app) versions up to and including the current release, requires an authenticated attacker (PR:L) who previously held a legitimate override and an admin-run transfer_app() operation, and is bounded to integrity impact with no data disclosure or outage. No public exploit identified at time of analysis, and no vendor-released patch was available at publication.
Information disclosure in Capgo (Cap-go) before 12.128.2 allows unauthenticated network attackers to enumerate valid app IDs by observing differential error responses from the public.transfer_app RPC endpoint, requiring only a publishable API key. The root cause is a CWE-203 observable discrepancy: the endpoint returns distinguishable error messages depending on whether a supplied app ID exists or not, functioning as an existence oracle. No active exploitation is confirmed (not in CISA KEV), but the low barrier to exploitation - network-accessible, no authentication beyond a publishable key - makes this a practical reconnaissance primitive against Capgo-hosted applications.
Authorization bypass in Capgo (cap-go before 12.128.2) allows holders of org-limited API keys to read membership data from organizations outside their assigned scope by calling the GET /organization/members endpoint without proper enforcement of limited_to_orgs restrictions. Exposed fields include uid, email, image_url, role, and is_tmp - sufficient to enumerate organization membership and email addresses across tenants. No public exploit identified at time of analysis; CVSS 4.0 scores this at 5.3 reflecting a low-privilege, network-accessible attack with limited confidentiality impact.
Unauthenticated job ID enumeration in Cap-go (Capgo) before version 12.128.2 exposes internal builder job identifiers via observable response discrepancies on the OPTIONS /build/upload/:jobId/* endpoint. Any network-accessible attacker can probe this endpoint without credentials to distinguish valid job IDs from invalid ones, effectively building a map of active build jobs. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the zero-barrier exploitation (no auth, no interaction) and dual impact of information disclosure and incidental resource consumption make it a meaningful exposure for organizations running self-hosted Capgo instances.
Broken cursor pagination in Capgo's /private/devices endpoint on the Cloudflare/workerd runtime path allows authenticated attackers with app.read_devices permission to trigger infinite duplicate-page loops, making later dataset rows permanently unreachable for affected sessions. All Capgo versions before 12.128.12 are vulnerable, and the impact is operational: device-management workflows repeatedly process the same duplicate records while failing to advance through the full dataset. No public exploit identified at time of analysis, and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 5.3 (Medium) reflects limited, availability-only impact scoped to the vulnerable system.
Cross-tenant information disclosure in Capgo (cap-go/capgo) before version 12.128.2 exposes per-organization usage telemetry to any caller holding the publicly distributed Supabase API key. Three PostgREST RPC functions - get_app_metrics, get_global_metrics, and get_total_metrics - are granted to the Supabase anon role without enforcing org membership or permission checks, allowing queries against arbitrary org_id values to return MAU, bandwidth, installs, and app IDs belonging to other tenants. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; a vendor-released patch exists at version 12.128.2.
Capgo's Enforce Password Policy feature in versions before 12.128.2 permanently locks Super Admins out of their organization through a backend state management flaw, constituting a targeted denial-of-service against administrative access. When a Super Admin enables the password policy and successfully changes their password to a policy-compliant value, the backend fails to mark the account compliant, trapping the account in an infinite forced-password-reset loop and severing all organization management access. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 6.9 reflects the high-privilege prerequisite and pure availability impact with no confidentiality or integrity consequence.
Orphaned profile image retention in Capgo before 12.128.2 exposes previously uploaded user images indefinitely after replacement or deletion, because the backend storage object is never purged when the application record is updated. Attackers who possess a prior image URL - obtained via browser history, referrer logs, network interception, or prior caching - can retrieve user-uploaded content even after the user intended to remove it, violating data erasure expectations. No public exploit has been identified at time of analysis, and the CVSS 4.0 vector (PR:L) indicates prior authenticated access or URL knowledge is a prerequisite, limiting opportunistic mass exploitation.
Improper authorization in Capgo App before 12.128.12 allows an authenticated organization member to mint a non-expiring, app-scoped API key even when the owning organization has enabled require_apikey_expiration and configured a max_apikey_expiration_days limit. The POST /apikey handler resolves the target app from the supplied app_id but omits the owning organization from the list passed to validateExpirationAgainstOrgPolicies when org_id, limited_to_orgs, and expires_at are absent, so the validation returns early and the expiration policy is silently skipped. Exploitation requires a valid org account with permission to create app-scoped keys and an organization that actually has the policy configured; the only privilege gained is indefinite key lifetime, and no public exploit code was identified at time of analysis. The vendor fixed the issue in version 12.128.12.
Capgo's Supabase backend bundle-promotion API allows an authenticated API key holder with app-level channel.promote_bundle to bypass explicit per-channel deny overrides and promote a bundle to a channel they were denied, updating public.channels.version. This affects Capgo (Cap-go/capgo.app) deployments, confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and likely earlier versions; no vendor-released patch was known at publication. The flaw only has impact when an administrator has configured a per-channel allow or deny override on the target channel_id, and no public exploit identified at time of analysis; the vendor/VulnCheck CVSS 4.0 base score is 7.2.
Capgo's native build TUS upload proxy forwards a user-controlled TUS resource suffix to the builder service while injecting Capgo's own privileged builder API key, without ever binding that suffix to the upload_path or upload_session_key of the build job the caller was actually authorized for, allowing cross-job writes to another build's upload resource. All versions of capgo.app are affected, and no vendor patch was available at the time of the advisory publication. Exploitation is access-gated rather than anonymous: it requires a valid Capgo API key of scope 'all' or 'write' carrying app.build_native permission for at least one application (plus a legitimate proxy path from an active job A), and knowledge of another job's (job B's) TUS resource suffix, so the realistic impact is integrity-only - corruption of build artifacts - with no read/exfiltration or availability loss, and no public exploit code has been identified at time of analysis.
Capgo's direct exposure of the public.org_users table through Supabase PostgREST lets an authenticated user who already holds admin rights in an organization bypass the invitation and role-assignment workflow entirely, inserting or updating org_users rows to add any existing public.users account as an active member with user_right="admin". The vulnerable row-level security policies only enforce public.check_min_rights('admin', ...), so they skip the pending-invitation check in tmp_users, the /private/accept_invitation token flow, and the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. Per this assessment the practical impact is a moderate authorization flaw (PR:L, C:L/I:H/A:N) rather than a near-critical event; all versions are affected, no public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (it is not in CISA KEV).
Unauthenticated retrieval of deleted over-the-air update bundles from capgo.app through version 12.129.0 is possible via the public file read endpoint, which fails to check an artifact's deletion status before serving it; a cache hit additionally triggers restoration of the deleted object back into R2 storage. Any party holding a previously issued cached bundle URL can read content the operator believed was deleted, and the secondary restoration side effect re-persists that content. Exploitation requires a valid, previously recorded cached URL for a since-deleted and cached bundle - attackers cannot mint access from nothing - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis. Risk is driven by the precondition of a leaked or harvested cache URL, the vendor (VulnCheck) rating this CVSS 4.0 8.7 with high confidentiality impact, while our own assessment scores it lower (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) because the dependent-on-a-valid-cached-URL and cached-then-deleted preconditions materially limit realistic exposure.
Authenticated principals who hold an app-scoped upload/write/all API key with upload+ rights - or any user granted write+ rights on a target app - can poison Capgo's OTA update manifest so that client devices receive attacker-controlled download URLs. The bypass works because the on_version_update async worker runs with the Supabase service-role client and implicitly trusts the manifest field of an app_versions row whose storage_provider is 'r2-direct', a configuration excluded from the bundle content-lock check; the worker then writes attacker-supplied file_name, file_hash and s3_path values into public.manifest, and once a channel points at the crafted version the /updates endpoint serves the injected record as a client-facing download_url. All versions are affected, no vendor patch was available at time of publication, and no public exploit code has been identified at time of analysis.
An authenticated holder of an app-limited write API key on Capgo (capgo.app) can abuse the PUT /app/:id endpoint's user-controlled `icon` field to make a privileged service-role worker rewrite a private storage object belonging to another tenant, such as an organization logo, that the API key cannot read or write directly under Supabase Storage RLS. The flaw is a cross-tenant authorization bypass (CWE-639 / confused deputy) rather than remote code execution: the attacker cannot read the targeted object, cannot supply arbitrary replacement content beyond the referenced object being re-uploaded with cleaned metadata, and must already possess a scoped write API key for at least one app on the instance. Our independent assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N and considers the vendor's 8.7 (PR:N) rating materially overstated; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated administrators on Capgo (capgo.app) can grant channel-scoped permissions to non-member users because the platform fails to validate that principals in channel_permission_overrides belong to the organization (CWE-862). Attackers with app or org admin privileges can insert override rows with arbitrary external user UUIDs, enabling those external users to exercise permissions such as channel.promote_bundle and push over-the-air bundles to a channel. Exploitation requires an existing admin account; no public exploit code has been identified at time of analysis, and the vendor's CVSS 4.0 score of 8.7 appears generous given the high privilege prerequisite and the limited confidentiality and integrity impact assessed as moderate priority.
Authenticated organization admins in capgo.app can corrupt the organization's Stripe billing pointer (customer_id) by sending a direct UPDATE to the Supabase PostgREST API, bypassing the official organization update endpoint that excludes this column. The flaw requires an org admin with org.update_settings but without org.update_billing, and only affects the attacker's own organization's plan/billing state, not broader system data. No vendor patch was available at the time of the advisory, and no public exploit code has been identified.
Privilege escalation in Capgo (capgo.app) before 12.267.1 allows a principal holding the apikey_manager role to rotate a higher-privileged same-owner sibling API key - such as an org_super_admin key - via the API key rotation PUT endpoint and retrieve the replacement plaintext secret, giving the attacker the credentials of the stronger principal. Exploitation is authenticated: the attacker must already possess or have compromised an apikey_manager key, and a more privileged sibling key under the same owner must exist, which limits exposure to organizations that delegate key-management duties to lower-trust roles. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; a vendor fix is available in 12.267.1.
Cross-tenant metadata modification in Capgo before 12.244.1 allows an authenticated attacker to alter image object metadata belonging to other tenants by exploiting a confused-deputy metadata-cleaning worker that fails to validate object-key ownership. The vulnerability requires knowledge of a victim tenant's image object key and the ability to update database rows containing image keys; it results in integrity impact only, with no confidentiality or availability impact, and no public exploit has been identified at time of analysis.
Vertical privilege escalation and account takeover in Capgo (capgo.app) through 12.261.0: an authenticated attacker who already holds the org_admin tier permission org.update_settings can rewrite the provider_id column of a public.sso_providers row over PostgREST and point the organization's email-domain trust anchor at an identity provider they control, after which the server-side SSO merge routine binds the attacker's identity to the legitimate org owner account, nulls that account's password, and deletes its other identities and sessions. The impact is full owner/super_admin takeover plus lockout of the real owner, although exploitation is gated on the target organization having an active SSO provider configured and on the attacker already possessing org_admin in that organization; no public exploit code was identified at time of analysis and there is no CISA KEV entry. The incomplete nature of the fix (a BEFORE UPDATE guard that freezes dns_verified_at, domain, status and enforce_sso but leaves provider_id, metadata_url and attribute_mapping writable under a table-wide ALL grant with only row-scoped RLS) makes this a durable privilege-escalation path rather than a one-off misconfiguration.
Privilege escalation in the Capgo capgo.app backend (versions ≤ 12.261.0) lets an authenticated user who holds only the apikey_manager organization role mint API keys bound to higher-privileged deploy roles (app_developer, app_uploader, channel_developer, channel_uploader). Those keys can in turn be used to push arbitrary over-the-air JavaScript updates to every end user of the organization's apps, giving an insider or delegated-role holder unauthorized write access to production app content. Exploitation requires a valid JWT session and the apikey_manager role (authenticated, no user interaction), no public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; at advisory publication no patched version was available.
Improper access control in Capgo (capgo.app) lets any holder of an ordinary full API key forge a trusted SSO provider by writing directly to the public.sso_providers table exposed via Supabase PostgREST, setting status='active' and enforce_sso=true without passing the backend provisioning route. This sidesteps the Enterprise-plan gate, Supabase Management API provider creation, DNS TXT domain-ownership verification, and the pending_verification→verified→active workflow, so an attacker can assert SSO enforcement for arbitrary unverified domains and disrupt normal login. All versions are affected, no patch was available at advisory time, and there is no public exploit identified at time of analysis beyond the VulnCheck write-up.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Privilege escalation in the Capgo (capgo.app) backend through version 12.242.4 allows an authenticated API key holder to impersonate a more privileged sibling key by supplying its numeric ID in the `x-limited-key-id` header, bypassing the intended parent-child delegation hierarchy entirely. The middleware's `checkKeyByIdPg()` resolves the caller-supplied key ID using only the ID, expiration state, and owning `user_id`, while `validateSubkeyUser()` only checks that both keys share an owner - neither function verifies that the resolved key is an actual descendant of the authenticating key. An `apikey_manager` key can therefore silently acquire `app_admin` permissions via `setSubkeyAuthContext` without knowledge of the target key's secret; the issue was confirmed on release 12.242.4 after a prior incomplete fix (GHSA-8h52-44r7-w343), and no patched version was available at time of advisory.
Capgo's MFA enforcement is defeated by an authentication assurance level (AAL) mismatch across two distinct code paths: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts Supabase JWTs without inspecting the aal claim, and the direct RBAC path (checkPermissionPg() calling public.rbac_check_permission_direct() in rbac.ts) authorizes operations by user ID alone, bypassing the assurance-level check that public.verify_mfa() correctly enforces. An attacker holding only the victim's account password can authenticate, receive an aal1 JWT, exercise privileged RBAC operations without triggering any MFA challenge, mint a persistent app_admin API key, and modify production OTA channel configurations - all of which survive logout of the original aal1 session. No patched version has been released; all versions of capgo.app are affected, and the advisory includes a validated proof-of-concept demonstrating bundle swap on a production channel.
Authorization bypass in Capgo (capgo.app), a live-update/OTA platform for Capacitor mobile apps, allows a de-provisioned user to retain channel-level permissions after their organization RBAC access has been revoked. Because Capgo does not clean up channel permission overrides when a user's last organization role binding is deleted, stale grants remain active - letting the former member perform privileged actions such as pushing or changing production OTA update versions. Reported by VulnCheck (GHSA-qfxq-2ch8-hjg9); no public exploit identified at time of analysis.
Unauthenticated organization enumeration in Capgo before 12.128.2 lets attackers abuse the Supabase PostgREST SECURITY DEFINER RPC public.rescind_invitation, which returns distinguishable NO_ORG versus NO_RIGHTS errors when invoked with only a publishable (anon) API key. This oracle lets remote unauthenticated attackers confirm which organization IDs exist, building a target list for follow-on phishing and social engineering. Reported by VulnCheck; no public exploit code and no CISA KEV listing at time of analysis.
Cross-tenant data poisoning in Supabase Capgo before 12.128.2 allows remote unauthenticated attackers to corrupt billing and quota records by invoking the SECURITY DEFINER record_build_time RPC with only a public anon API key. The flaw stems from missing authorization inside a privilege-elevated PostgREST function, enabling arbitrary build-time inserts against any organization. No public exploit identified at time of analysis, but the trivial network-reachable invocation pattern makes weaponization straightforward.
Unauthenticated denial of service in Cap-go capgo (capgo-backend) before 12.128.12 allows remote attackers to exhaust PostgreSQL resources by sending unfiltered queries to the public.audit_logs PostgREST endpoint using the public anon key. Because the query planner runs expensive logic before Row-Level Security rejection, repeated requests trigger statement timeouts (error 57014) and cascade into HTTP 500 failures on unrelated endpoints such as /orgs. No public exploit identified at time of analysis, though the technique is fully described in the GHSA advisory.
Privilege inversion in Cap-go (Capgo) before 12.128.2 lets holders of read-only API keys cancel running native builds by abusing the GET /build/logs/:jobId SSE endpoint. On client disconnect the server invokes cancelBuildOnDisconnect() using the privileged BUILDER_API_KEY, bypassing the app.build_native permission enforced on POST /build/cancel/:jobId. No public exploit identified at time of analysis, but the issue is trivially reproducible against any deployment exposing the log stream.
SQL injection in Capgo (cap-go) before 12.128.2 allows authenticated users with read-level API keys to access analytics data belonging to other tenants by injecting arbitrary SQL through multiple unparameterized parameters in cloudflare.ts. The flaw stems from direct string interpolation of request-body values into Cloudflare Analytics Engine queries, enabling cross-tenant data exposure. No public exploit identified at time of analysis, though a VulnCheck advisory and an upstream GitHub Security Advisory document the issue.
Cross-tenant billing log tampering in Capgo (Cap-go/capgo) before 12.128.2 allows unauthenticated attackers holding only the public Supabase publishable anon key to insert or overwrite build_logs rows for arbitrary organizations via the SECURITY DEFINER PostgREST RPC public.record_build_time. Because the function is granted to the anon role and uses ON CONFLICT (build_id, org_id) DO UPDATE, attackers can inflate or alter another tenant's billable build time, producing financial-impact denial of service. No public exploit identified at time of analysis, though the vendor advisory (GHSA-42xj-3h9w-26h5) and a VulnCheck write-up describe the attack path in detail.
Account pre-registration hijack in Capgo before 12.128.2 lets a remote unauthenticated attacker claim an account under a victim's email address before that email is verified, then lock the legitimate owner out by enabling two-factor authentication on the squatted account. The flaw stems from a CWE-640 weak password recovery / account-binding logic issue and carries a CVSS 4.0 score of 9.3; no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Authentication bypass in Capgo prior to version 12.128.2 lets attackers defeat email-based OTP verification by tampering with HTTP responses returned to the client, which the application trusts to decide whether verification succeeded. Successful exploitation enables fraudulent 2FA enrollment and account takeover, and no public exploit has been identified at time of analysis though VulnCheck has published an advisory describing the response-manipulation technique.
Denial of service in Capgo Console versions prior to 12.28.2 allows an authenticated attacker to lock legitimate users out of authentication and onboarding flows by triggering account deletion while a device identifier is bound to the active session. The platform incorrectly persists the deletion state against the device identifier rather than the account, causing the affected browser or device to be redirected to an account-disabled page for roughly 30 days. No public exploit identified at time of analysis, but a vendor patch and GHSA advisory (GHSA-qmrm-qgwr-55jf) have been published following disclosure by VulnCheck.
Account takeover in Cap-go (Capgo) versions prior to 12.128.2 allows an attacker holding a temporary authenticated session to change the account's registered email address without re-authentication (no password or MFA prompt), then trigger a password reset to attacker-controlled inbox and seize the account. The flaw, reported by VulnCheck and tracked as a missing-authentication weakness (CWE-306), has a vendor patch but no public exploit identified at time of analysis.
An insecure direct object reference in Capgo through 12.128.2 lets any authenticated tenant user read cross-tenant objects stored in the private images bucket by supplying attacker-controlled icon storage paths to the PUT /app/:appId endpoint, which then returns service-role-signed URLs valid for 7 days. Because the signed URLs bypass per-tenant authorization, exposed assets include user avatars, organization logos, and app icons. Exploitation requires a valid non-privileged Capgo account and yields only low-sensitivity read access; no modification or availability impact is possible, and no public exploit code was identified at time of analysis.
Authenticated users who hold the app.build_native permission for a given app in Capgo.app before 12.264.5 can keep writing to a native build upload session after its stored one-hour upload_expires_at has passed or after the build has moved beyond the upload phase, because the TUS proxy at /build/upload/:jobId enforces only the build_native permission and never checks upload expiry or build lifecycle state. The proxy loads just app_id, owner_org, builder_job_id and upload_path and then forwards POST, PATCH and HEAD requests to the internal builder, so stale or out-of-phase sessions remain writable. The weakness maps to CWE-613 (Insufficient Session Expiration) with low integrity and availability impact (CVSS v3.1 5.3, AV:N/AC:L/PR:L/UI:N), there is no public exploit identified at time of analysis, and the flaw can be neutralized entirely if the separate downstream builder service rejects the stale request on its own.
Incomplete content-lock enforcement in Capgo (capgo.app) lets an authenticated holder of an API key with bundle write/upload permission keep or create an app_versions row in the `r2-direct` storage_provider state and then mutate delivery-critical columns - including checksum, session_key, key_id, manifest, r2_path, external_url and native_packages - via direct PostgREST requests. Because the channel/version join used by the `/updates` endpoint filters only deleted versions and does not exclude `r2-direct` rows, the tampered bundle remains OTA-selectable and altered metadata is served to client devices. Exploitation is authenticated only (the assessed vector requires PR:L), is confined to bundles the key can already write, and yields metadata tampering over OTA rather than server-side code execution; all versions are affected and no vendor-released patch was identified at the time of analysis, with no public exploit identified at time of analysis.
Stale channel permission overrides in Capgo can let a former source-organization member repoint a destination-owned app channel after a cross-organization app transfer, causing the /updates endpoint to serve an attacker-selected OTA bundle to devices. The flaw affects all Capgo (capgo.app) versions up to and including the current release, requires an authenticated attacker (PR:L) who previously held a legitimate override and an admin-run transfer_app() operation, and is bounded to integrity impact with no data disclosure or outage. No public exploit identified at time of analysis, and no vendor-released patch was available at publication.
Information disclosure in Capgo (Cap-go) before 12.128.2 allows unauthenticated network attackers to enumerate valid app IDs by observing differential error responses from the public.transfer_app RPC endpoint, requiring only a publishable API key. The root cause is a CWE-203 observable discrepancy: the endpoint returns distinguishable error messages depending on whether a supplied app ID exists or not, functioning as an existence oracle. No active exploitation is confirmed (not in CISA KEV), but the low barrier to exploitation - network-accessible, no authentication beyond a publishable key - makes this a practical reconnaissance primitive against Capgo-hosted applications.
Authorization bypass in Capgo (cap-go before 12.128.2) allows holders of org-limited API keys to read membership data from organizations outside their assigned scope by calling the GET /organization/members endpoint without proper enforcement of limited_to_orgs restrictions. Exposed fields include uid, email, image_url, role, and is_tmp - sufficient to enumerate organization membership and email addresses across tenants. No public exploit identified at time of analysis; CVSS 4.0 scores this at 5.3 reflecting a low-privilege, network-accessible attack with limited confidentiality impact.
Unauthenticated job ID enumeration in Cap-go (Capgo) before version 12.128.2 exposes internal builder job identifiers via observable response discrepancies on the OPTIONS /build/upload/:jobId/* endpoint. Any network-accessible attacker can probe this endpoint without credentials to distinguish valid job IDs from invalid ones, effectively building a map of active build jobs. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the zero-barrier exploitation (no auth, no interaction) and dual impact of information disclosure and incidental resource consumption make it a meaningful exposure for organizations running self-hosted Capgo instances.
Broken cursor pagination in Capgo's /private/devices endpoint on the Cloudflare/workerd runtime path allows authenticated attackers with app.read_devices permission to trigger infinite duplicate-page loops, making later dataset rows permanently unreachable for affected sessions. All Capgo versions before 12.128.12 are vulnerable, and the impact is operational: device-management workflows repeatedly process the same duplicate records while failing to advance through the full dataset. No public exploit identified at time of analysis, and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 5.3 (Medium) reflects limited, availability-only impact scoped to the vulnerable system.
Cross-tenant information disclosure in Capgo (cap-go/capgo) before version 12.128.2 exposes per-organization usage telemetry to any caller holding the publicly distributed Supabase API key. Three PostgREST RPC functions - get_app_metrics, get_global_metrics, and get_total_metrics - are granted to the Supabase anon role without enforcing org membership or permission checks, allowing queries against arbitrary org_id values to return MAU, bandwidth, installs, and app IDs belonging to other tenants. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; a vendor-released patch exists at version 12.128.2.
Capgo's Enforce Password Policy feature in versions before 12.128.2 permanently locks Super Admins out of their organization through a backend state management flaw, constituting a targeted denial-of-service against administrative access. When a Super Admin enables the password policy and successfully changes their password to a policy-compliant value, the backend fails to mark the account compliant, trapping the account in an infinite forced-password-reset loop and severing all organization management access. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 6.9 reflects the high-privilege prerequisite and pure availability impact with no confidentiality or integrity consequence.
Orphaned profile image retention in Capgo before 12.128.2 exposes previously uploaded user images indefinitely after replacement or deletion, because the backend storage object is never purged when the application record is updated. Attackers who possess a prior image URL - obtained via browser history, referrer logs, network interception, or prior caching - can retrieve user-uploaded content even after the user intended to remove it, violating data erasure expectations. No public exploit has been identified at time of analysis, and the CVSS 4.0 vector (PR:L) indicates prior authenticated access or URL knowledge is a prerequisite, limiting opportunistic mass exploitation.