Judel777

An authorization flaw exists in the `checkPermissionsForCreateOrUpdate()` function within the `Multitenancy` class. In licensed multi-tenant deployments where multiple applications share a non-default connection URI domain and use separate `api keys`, an attacker with a valid API key for one application can update the parent connection URI domain. This occurs because the system fails to require the source application and tenant to be public when checking the domain during create or update operations. Consequently, an attacker can replace the parent key and sibling application keys, modify sibling users, hijack sessions, and establish persistence via sibling dashboard users. Additionally, omitting the optional identifier in v2 create or update handlers allows an attacker to target the base tenant, bypassing permission checks and enterprise-feature gates to modify `firstFactors`, required secondary factors, and recipe-enabled flags, which compromises login integrity and availability.

The application fails to validate that principals within `channel permission overrides` are members of the organization. This allows authenticated app or organization administrators to grant channel permissions to users outside the organization by inserting override rows with arbitrary external user UUIDs. This can lead to the unauthorized granting of channel-scoped permissions, such as `channel.promote bundle`.

An incomplete access-control and content-lock enforcement issue exists where the `enforce encrypted bundle trigger` and `check encrypted bundle on insert` locks exempt rows in `app versions` if the previous `storage provider` is `r2-direct`. This allows delivery-critical columns—including `name`, `app id`, `session key`, `key id`, `storage provider`, `r2 path`, `external url`, `checksum`, `manifest`, and `native packages`—to remain mutable. Additionally, the `/updates` endpoint does not exclude `r2-direct` versions, making them selectable for Over-the-Air (OTA) updates. An attacker with an API key possessing bundle write or upload permissions can maintain a bundle in the `r2-direct` state and modify these fields via PostgREST requests, resulting in altered bundle metadata being served to devices.

An authenticated organization member can create a non-expiring app-scoped API key, bypassing the organization's API key expiration policy. This occurs when the owning organization has `require apikey expiration` enabled and a `max apikey expiration days` limit configured. In the 'POST /apikey' endpoint, requests that provide `app id` but omit `org id`, `limited to orgs`, and `expires at` fail to add the app's owner organization to the list of IDs passed to the `validateExpirationAgainstOrgPolicies()` function. Because the list is empty, the validation process returns early without enforcing the expiration policy.

A native build TUS upload proxy at the endpoint `supabase/functions/ backend/public/build/upload.ts` improperly handles authorization. The proxy validates the caller against a specific build job using the `builder job id` and checks the stored `upload path`, but it forwards a user-controlled TUS resource suffix from the path `/build/upload/:jobId/*` to the builder service while injecting a privileged builder API key. Since the forwarded suffix is not bound to the authorized job's `upload path` or `upload session key`, an attacker with a valid 'all' or 'write' Capgo API key and `app.build native` permission for one application can write to the TUS upload resource of a different job, provided the resource suffix is known, leading to the corruption of build artifacts.

An issue exists in the row-level security UPDATE policy on the `public.orgs` table. An authenticated organization administrator with `org.update settings` permissions can bypass the official organization update endpoint `supabase/functions/ backend/public/organization/put.ts` and the private Stripe billing route by sending an update directly to Supabase PostgREST. This allows the user to modify the internal billing pointer column `customer id`, even without the `org.update billing` permission. By nulling or corrupting this value, the user can cause plan and billing checks to fail, effectively moving the organization from a paid plan to an unpaid or no-plan state.

🚨 CVE-2026-100623 Capgo (capgo.app) exposes the legacy membership table public.org users directly through Supabase PostgREST. The table's row-level security policies "Allow org admin to insert" and "Allow org admin to update" only verify that the caller has admin rights in the target organization (public.check min rights('admin', ...)); they do not require a pending invitation in tmp users, acceptance of an invite token via /private/accept invitation, any action by the target user, or the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. As a result, an authenticated user who is an admin of an organization can INSERT or UPDATE org users rows directly to add any existing public.users account as an active member of that organization with user right="admin", bypassing the invitation and role-assignment workflow entirely. In testing, an account with no prior access to the organization or its apps could, after such a direct insert, read the organization and app and pass check min rights. All versions are affected and no patch was available at the time of publication. 🎖@cveNotify

The `transfer app()` database function fails to delete or revalidate existing rows in `channel permission overrides` when transferring an app, its channels, versions, and related records to a destination organization. This allows a user who had a channel permission override in the source organization to retain that override after the transfer, despite having no membership or Role-Based Access Control (RBAC) binding in the destination organization. An attacker can use an authenticated JSON Web Token (JWT) against the PostgREST API to modify the destination-owned channel to point to a different bundle, leading the `/updates` endpoint to serve an unauthorized application version to devices.

An indirect bypass of the row-level security policy exists in the `public.manifest` table. A user or principal with app-scoped upload, write, or all API keys, or an authenticated user with write+ rights, can update `public.app versions.manifest` for versions using the `r2-direct` storage provider, as these are not covered by the bundle content-lock check. The `on version update` async worker trusts the `record.manifest` and uses a service-role Supabase client to insert attacker-controlled `file name`, `file hash`, and `s3 path` variables into the `public.manifest` table. Consequently, the `/updates` endpoint returns this entry as a client-facing `download url`, allowing for Over-the-Air (OTA) manifest poisoning. OTA refers to the wireless delivery of updates to a device.

An authorization flaw exists in the app icon update process. The 'PUT /app/:id' endpoint accepts a user-controlled `icon` value and stores it in `public.apps.icon url` without verifying if the image path belongs to the target app's image namespace. Updating this value triggers the `on app update` trigger, which executes the `cleanStoredImageMetadata()` function using service-role credentials. This process downloads and re-uploads the referenced storage object with `upsert: true`. Consequently, an authenticated user with an app-limited write API key can force the privileged worker to overwrite private image objects, such as organization logos, that the user cannot normally access under Supabase Storage Row Level Security (RLS), a security feature that restricts data access based on user roles.

The '/build/upload/:jobId' TUS proxy endpoint fails to enforce upload expiry or build lifecycle state. While native build requests include an `upload expires at` timestamp and a 'pending' status, the upload proxy only verifies the `app.build native` permission before forwarding POST, PATCH, and HEAD requests to the internal builder. Consequently, an authenticated user with the `app.build native` permission can continue writing to a build upload session after the expiry time has passed or after the build has progressed beyond the upload phase, provided the internal builder service does not independently reject the request.

The backend fails to validate parent-child delegation when processing the `x-limited-key-id` header. The function `checkKeyByIdPg()` in `supabase/functions/ backend/utils/hono middleware.ts` resolves the numeric API key ID using only the key ID, expiration state, and the authenticating key's `user id`. Simultaneously, `hasLimitedRbacSubkeyScope()` accepts any key with a non-organization RBAC binding, and `validateSubkeyUser()` only compares owning user IDs. This allows an authenticated `apikey manager` API key without application access to provide the numeric ID of a more privileged key owned by the same user. The middleware then uses `setSubkeyAuthContext` to replace the authenticated principal and secret with that of the privileged key, enabling the user to exercise `app admin` permissions without knowing the secret.

Capgo (capgo.app) fails to restrict direct write access to the public.sso providers table exposed through Supabase PostgREST. A holder of an ordinary Capgo full API key can insert a row with status='active' and enforce sso=true, bypassing the intended backend SSO provisioning route (supabase/functions/ backend/private/sso/providers.ts) and its controls: the Enterprise plan requirement, SSO provider creation via the Supabase Management API, DNS TXT domain-ownership verification, the pending verification → verified → active status transition, and issuance of a trusted provider ID by Supabase Auth. The forged row is trusted by SSO discovery and enforcement logic, including the unauthenticated login preflight endpoint /private/sso/check-domain, which then reports {"has sso": true, "enforce sso": true} for domains that were never verified, allowing attacker-controlled SSO enforcement to be asserted for arbitrary domains and disrupting normal login. All versions are affected; at the time of the advisory no patch was available.

Capgo fails to clean up channel permission overrides when a user's last organization role binding is deleted, which leaves stale overrides active. This allows attackers to retain channel-specific permissions even after their base Role-Based Access Control (RBAC) access has been revoked, enabling unauthorized actions such as modifying production Over-the-Air (OTA) versions.

Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions (no patched version available at time of publication). The Edge authorization path allows a password-only Supabase aal1 session to exercise privileged RBAC permissions even when the account has a verified MFA factor that has not been used for the session: the Edge JWT middleware (foundJWT() in supabase/functions/ backend/utils/hono middleware.ts) accepts the JWT without validating its assurance level, and the direct RBAC path (checkPermission()/checkPermissionPg() in supabase/functions/ backend/utils/rbac.ts calling public.rbac check permission direct()) authorizes by user ID without passing or checking the session aal, unlike the public.verify mfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped app admin API key that remains valid after the aal1 session is logged out, and perform privileged operations such as modifying production OTA channel configurations (validated by changing a public production channel from bundle 1.0.0 to 1.0.1), defeating the protection provided by MFA.

An information disclosure issue exists in the Supabase PostgREST SECURITY DEFINER RPC function `public.rescind invitation()`. Unauthenticated attackers using only a publishable API key can enumerate the existence of organizations. This is possible because the function returns distinct error messages, specifically `NO ORG` and `NO RIGHTS`, allowing attackers to identify valid organization IDs. This discovery can be used to facilitate targeted phishing or social engineering campaigns.

An issue exists where users demoted from the `super admin` role retain unauthorized access to specific functions. This occurs because the `org users.user right` column is not cleared during the deletion of role bindings, leading to stale permissions. An attacker can use this to enumerate and bulk delete non-compliant bundles across an entire organization. The affected functions are the `delete non compliant bundles` and `count non compliant bundles` RPCs.

An information disclosure issue exists in the Supabase PostgREST `global stats` endpoint. Unauthenticated attackers can use the public `apikey` to query the '/rest/v1/global stats' endpoint, exposing sensitive financial and operational metrics, including Monthly Recurring Revenue (MRR), total revenue, plan-tier revenue breakdown, customer counts, and operational telemetry.

A scope isolation issue exists in the 'POST /webhooks/test' endpoint. This flaw allows users with app-scoped API keys to execute organization-scoped webhook operations, bypassing the `limited to apps` authorization check. Consequently, an attacker using app-scoped credentials can trigger signed outbound webhook deliveries for arbitrary organization webhooks that fall outside their designated app boundary.

A cross-organization account disruption issue exists in the SSO prelink endpoint. Enterprise administrators possessing the `org.update settings` permission and an active SSO provider can utilize the `prelink-users` endpoint to permanently delete the password identities of users belonging to other organizations, provided the users match the provider's email domain. This action forces the affected users to either use the attacker's SSO provider or undergo a password reset recovery process.