Supabase Auth, a JWT‑based service that manages users and issues JWT tokens, has a flaw in versions prior to 2.185.0 that permits an attacker to create valid sessions for any user. By forging an asymmetrically signed ID token that appears to come from a legitimate issuer (Apple or Azure) and contains the target user’s email, the attacker submits this token to the Auth token endpoint. The server, trusting the issuer and verifying the token, associates the victim’s existing OIDC identity with the attacker’s identity and issues a new access and refresh token at the AAL1 level. This allows the attacker to impersonate the victim, gaining full read‑write access to the victim’s account and any resources protected by Supabase Auth. The weakness is a failure to properly limit the trust in external ID tokens (CWE‑290).

The vulnerability affects Supabase Auth for all versions older than 2.185.0. Any deployment using Supabase Auth 2.x (or earlier) with the Apple or Azure authentication provider enabled is potentially compromised. The vendor product cpe is cpe:2.3:a:supabase:auth:*:*:*:*:*:*:*:*.

The CVSS score of 4.8 indicates a moderate impact, with a low probability of exploitation (EPSS <1%) and no listing in the CISA KEV catalog. Exploitation requires an attacker to possess a valid private signing key for a custom Apple or Azure issuer set up in the Supabase Auth instance, as well as the ability to perform HTTP requests to the token endpoint. Because the attack path is remote and the attacker must control the token issuer, the likelihood of successful exploitation in the wild is low, but organizations with exposed Apple or Azure providers should prioritize patching. Once patched in version 2.185.0, the vulnerability is resolved.