Supabase PostgreSQL v15.1 was discovered to contain a SQL injection vulnerability via the component /pgmeta/default/query. NOTE: the vendor's position is that this is an intended feature; also, it exists in the Supabase dashboard product, not the Supabase PostgreSQL product. Specifically, /pgmeta/default/query is for SQL queries that are entered in an intended UI by an authorized user. Nothing is injected.

Supabase Capgo before 12.128.2 contains an authorization bypass vulnerability in the SECURITY DEFINER recordbuildtime RPC function that allows unauthenticated attackers to insert arbitrary build-time records. Attackers can exploit this by calling POST /rest/v1/rpc/recordbuildtime with a public API key to poison billing and quota data for any organization, enabling resource exhaustion and cross-tenant billing manipulation.

capgo.app (npm package capgo) through version 12.207.1 does not compare the caller's role rank against the requested role in the validateInvite() function of supabase/functions/backend/private/invitenewusertoorg.ts. The POST /private/invitenewusertoorg endpoint only requires the org.updateuserroles permission for orgsuperadmin invitations, so an authenticated user holding only the org.inviteuser permission (e.g., an orgmember) can invite an external user as orgadmin or orgbillingadmin. When the invited account accepts the invitation via POST /private/acceptinvitation, ensureOrgMembership creates the role binding using the Supabase service-role key, which bypasses the preventrolebindingpriorityescalation and checkorguserprivileges database triggers. This allows privilege escalation resulting in full administrative control over the organization's apps, channels, members, and billing. The issue is addressed by pull request #3096, which compares the inviter's rank before permitting elevated invitations.

Supabase Auth is a JWT based API for managing users and issuing JWT tokens. Prior to 2.185.0, a vulnerability has been identified that allows an attacker to issue sessions for arbitrary users using specially crafted ID tokens when the Apple or Azure providers are enabled. The attacker issues a valid, asymmetrically signed ID token from their issuer for each victim email address, which then is sent to the Supabase Auth token endpoint using the ID token flow. If the ID token is OIDC compliant, the Auth server would validate it against the attacker-controlled issuer and link the existing OIDC identity (Apple or Azure) of the victim to an additional OIDC identity based on the ID token contents. The Auth server would then issue a valid user session (access and refresh tokens) at the AAL1 level to the attacker. This vulnerability is fixed in 2.185.0.

Impact The library functions getUserById, deleteUser, updateUserById, listFactors and deleteFactor did not require the user supplied values to be valid UUIDs. This could lead to a URL path traversal, resulting in the wrong API function being called.

Implementations that follow security best practice and validate user controlled inputs, such as the userId are not affected by this.

Patches Strict value checks have been added to all affected functions. These functions now require that the userId and factorId parameters MUST be valid UUID (v4).

Patched version: >= 2.69.1

Workarounds Implementations that follow security best practice and validate user controlled inputs, such as the userId are not affected by this. It is recommended that users of the auth-js library always follow security best practice and validate all inputs, before passing these to other functions or libraries.

References https://github.com/supabase/auth-js/pull/1063