Capgo before 12.128.2 contains an information disclosure vulnerability in the unauthenticated /private/sso/check-domain endpoint that returns internal orgid and providerid values. Attackers can enumerate email domains to build mappings of domains to organization UUIDs and SSO provider identifiers, enabling reconnaissance against Capgo tenants.

Capgo before 12.128.2 contains a scope isolation vulnerability in the POST /webhooks/test endpoint that allows app-scoped API keys to invoke org-scoped webhook operations. Attackers with app-scoped credentials can trigger signed outbound webhook deliveries for arbitrary organization webhooks outside their declared app boundary, bypassing the limitedtoapps authorization check.

Capgo before 12.128.2 contains a cross-tenant preview namespace collision vulnerability caused by non-bijective decoding of double underscores to dots in preview hostname parsing. Attackers can register app IDs with underscores that collide with other tenants' dotted app IDs, causing preview misrouting and denial of preview access for victim applications.

Capgo before 12.128.2 contains an authorization bypass vulnerability where write-scoped API keys can directly mutate protected channel configuration fields through PostgREST by exploiting a null authentication check in the immutability trigger. Attackers with write API keys can modify sensitive channel attributes such as public, allowemulator, and security-related flags outside intended application routes.

Capgo before 12.128.2 fails to enforce plan/quota restrictions on the /files/upload/attachments endpoint, allowing plan-blocked apps to create publicly readable R2 objects. Attackers can upload arbitrary attachments using upload-scoped API keys that bypass plan checks, persist outside normal bundle metadata, and survive app deletion, enabling storage and bandwidth abuse.

Capgo before 12.128.2 fails to strip EXIF metadata from images uploaded via the app information endpoint, exposing sensitive geolocation data. Attackers can upload images containing EXIF metadata to extract geographic location information and other embedded metadata from uploaded files.

Capgo before 12.128.2 contains a broken access control vulnerability in the organization management API where a scoped API key (limitedtoorgs) inherits its owner-user's permissions, allowing destructive cross-organization actions. When a user is an admin in two organizations and creates a write-mode API key restricted to one organization, that key can still perform destructive operations (e.g., DELETE /organization, DELETE /organization/members) against another organization. The root cause is route-level authorization (rbaccheckpermissiondirect) that evaluates the key owner's user privileges before enforcing the API key's limitedtoorgs scope.

Capgo before 12.128.2 allows upload-scoped API keys to modify the mutable appversions.r2path field through PostgREST, enabling retargeting to arbitrary R2 bundle objects. Attackers can patch r2path to point to victim objects, soft-delete the attacker-controlled version, and trigger the onversionupdate cleanup function to delete the victim R2 object, causing denial of service and bundle availability disruption.

Capgo before 12.128.2 contains a policy bypass vulnerability in appversions update enforcement that allows app-scoped API keys to downgrade encrypted bundles to non-encrypted state. Attackers with app-scoped all API keys can directly update the appversions table via PostgREST to clear sessionkey and keyid fields, bypassing organization-enforced encrypted-bundle policies and weakening OTA security controls.

Capgo before 12.128.2 contains improper error handling in the /private/acceptinvitation endpoint that returns HTTP 500 instead of safe 4xx errors when magicinvitestring is invalid. Attackers can trigger this vulnerability using only the public key by submitting malformed magicinvitestring values to cause server errors and leak internal processing details.

Capgo before 12.128.2 contains an authorization bypass vulnerability in the channel creation endpoint that allows authenticated users to overwrite existing channels by reusing their names. Attackers with app.createchannel permission can exploit a logic mismatch between existence validation and upsert operations to reassign channel ownership and modify critical production channel configurations.

Capgo before 12.128.2 allows org admins to assign org-scoped RBAC roles at app scope without validating role scope compatibility, including to pending invitees. Attackers can pre-seed malformed high-privilege bindings that survive invite acceptance, enabling accepted low-privilege users to perform unauthorized privileged app actions.

Capgo before 12.128.2 contains a broken object level authorization vulnerability in middlewareKey() that accepts the client-controlled x-limited-key-id header without validating ownership, allowing authenticated users to adopt cross-tenant limited keys. Attackers can supply another tenant's limited key ID to bypass authorization checks and access unauthorized cross-tenant resources across multiple API endpoints.

Capgo before 12.128.2 contains a denial of service vulnerability in the /auth/v1/otp endpoint that prevents email verification for two-factor authentication due to captcha validation failures. Authenticated users cannot complete 2FA enrollment as the backend consistently returns HTTP 500 errors with captcha verification process failed messages, blocking access to security controls.

Capgo before 12.128.2 contains an information disclosure vulnerability in the public.existappv2 RPC function that allows unauthenticated attackers to enumerate appids by calling POST /rest/v1/rpc/existappv2 with arbitrary appid parameters. Remote attackers can exploit this SECURITY DEFINER function to determine whether specific appids exist in the public.apps table, enabling cross-tenant app enumeration and privacy violations.

Capgo before 12.128.2 contains an unsecured images bucket lacking any row level security controls, allowing unauthenticated attackers to read, insert, and delete stored app icons. Remote attackers can exploit this misconfiguration to delete all icons and leak sensitive app IDs and user IDs.

Capgo before 12.128.2 allows direct patching of public.apps.ownerorg through PostgREST, bypassing the transferapp() workflow and creating split-brain ownership. Attackers can directly update apps.ownerorg while leaving appversions.ownerorg unchanged, enabling old-org keys to retain access to version data while new-org keys control the app record.

Capgo before 12.128.2 enforces mandatory two-factor authentication only at the UI level. Sensitive Organization (ORG) management API endpoints (e.g., editing organization details, inviting users) do not validate 2FA completion on the backend. An authenticated Admin user who has not enabled 2FA can replay or modify a previously captured ORG API request to perform privileged organization actions, bypassing the globally enforced 2FA requirement.

Capgo before 12.128.2 allows non-admin API keys to read webhook signing secrets via Supabase REST due to insufficient row-level security policies on the webhooks table. Attackers can retrieve the webhook secret and forge valid X-Capgo-Signature headers to send authenticated webhook events to configured receivers, breaking webhook authenticity and integrity.

Capgo before 12.128.2 contains a broken authentication vulnerability in its API key generation mechanism. API keys are exposed in frontend requests, and the backend fails to validate that keys are securely generated and bound to the authenticated user. An attacker can tamper with the API key parameter in the generation request and supply arbitrary values, generating custom API keys without proper authorization, which can lead to unauthorized access to protected endpoints.

Capgo before 12.128.2 contains a cross-domain SSO account takeover vulnerability in the provision-user endpoint that allows attackers to merge arbitrary victim accounts based on email match without validating SSO provider domain authorization. An attacker with enterprise org admin access and a malicious IdP can forge SAML assertions containing victim email addresses to trigger account merge and gain full access to victim accounts, organizations, and data.

Capgo before 12.128.2 contains a broken object level authorization (BOLA) vulnerability in the POST /build/start/:jobId and POST /build/cancel/:jobId endpoints. The handlers authorize the request based only on the attacker-controlled appid supplied in the request body and never verify that the jobId in the URL belongs to that appid (or the same tenant/org) before issuing privileged builder commands with the server-held builder API key. An authenticated user with the app.buildnative permission for any app they control can start or cancel arbitrary builder jobs belonging to other tenants by supplying a victim jobId, resulting in cross-tenant build sabotage (denial of service), unauthorized compute actions, and potential billing impact.

Capgo before 12.128.2 contains an information disclosure vulnerability in the unauthenticated /updates endpoint that resolves the defaultChannel parameter before enforcing privacy restrictions, allowing attackers to enumerate private channels and leak version/config state. Unauthenticated attackers can probe private channel names and distinguish valid channels from nonexistent ones based on response differences, revealing assigned bundle versions and platform-specific configuration details.

Capgo before 12.128.2 contains a credential validation vulnerability in the POST /functions/v1/private/validatepasswordcompliance endpoint that is callable using only the public Supabase key without authentication. The endpoint is CORS-permissive with wildcard origin allowance and lacks rate limiting, enabling attackers to perform password spraying and credential stuffing attacks to compromise user accounts.

Capgo before 12.128.2 contains a security control bypass vulnerability where the PostgREST/RLS plane accepts plaintext API keys through the capgkey header despite enforcehashedapikeys being enabled. Attackers can bypass org-level hashed-key enforcement by sending plaintext API keys directly to the PostgREST/RLS plane to access protected resources.

Capgo before 12.128.2 contains an authorization bypass vulnerability in its public API key management handlers (get/put/delete/post). API keys created with mode=all but restricted to a single app via limitedtoapps are only checked for limitedtoorgs and not for limitedtoapps, so an app-scoped key can enumerate, update, and delete sibling API keys belonging to the same account that are outside its declared app scope, enabling tampering with account-level credentials.

Capgo before 12.128.2 contains an authorization bypass vulnerability in POST /private/rolebindings that fails to verify appid ownership during app-scoped role binding creation. An attacker with administrative privileges in one organization can create role bindings targeting applications owned by other organizations, enabling unauthorized read and modification of victim applications.

Capgo before 12.128.2 contains a rate limit bypass vulnerability in the channelself endpoint that allows attackers to circumvent rate limiting by rotating the user-controlled deviceid parameter. Attackers can send multiple requests per second by changing deviceid values to flood the channeldevices table and cause database exhaustion.

Capgo before 12.128.2 contains an information disclosure vulnerability in the /functions/v1/channelself endpoint that allows unauthenticated attackers to enumerate non-public channel names and determine app existence and subscription status. Remote attackers can send GET requests with arbitrary appid parameters to disclose internal rollout channels, enumerate valid applications across tenants, and leak billing status without authentication or device binding.

Capgo (backend Supabase edge functions) before 12.128.2 does not apply the global authentication middleware to the GET /private/rolebindings/:orgid endpoint, unlike the POST and DELETE rolebindings routes, so unauthenticated requests reach the handler instead of being rejected at the middleware layer. The handler still performs its own authorization check and returns Unauthorized, so no direct data exposure occurs; the flaw is inconsistent authentication enforcement across HTTP methods that could enable authorization bypass if the handler logic changes.