Impact
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.
As of version 2.185.0 the vulnerability has been patched.
Attack Vector
The attack vector differs slightly for the Apple and Azure providers (steps below) and whether it is on the Supabase platform versus a self-hosted deployment. Prerequisites for both vectors are:
- An Auth server that has Apple or Azure providers enabled
- An OIDC-compliant, attacker-controlled ID token issuer accessible on the public Internet
- Email address(es) associated with user records in the Auth server
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 (see examples below). 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.
Azure
POST /token?grant_type=id_token
{
"provider": "azure",
"id_token": "<attacker controlled ID token>"
}
Apple
POST /token?grant_type=id_token
{
"provider": "apple",
"issuer": "<attacker controlled OIDC issuer URL>",
"id_token": "<attacker controlled ID token>"
}
Security Recommendations
Immediately update to version 2.185.0 or above if your self-hosted project relies on Apple or Azure authentication. If self-hosting establish a process to continuously and timely update your Auth server to the latest version.
To improve your application's security posture, consider enforcing MFA on all user accounts including verification on all sensitive actions of your application. If that is not possible consider re-authenticating or confirming sensitive data access or actions with your users by sending them an email or SMS message.
When self-hosting, never expose the Auth server directly on the internet. We recommend Auth be placed behind a reverse proxy (like Envoy, nginx, Caddy, Kong, or similar) which should be kept up-to-date.
To audit whether this vulnerability was exploited against your self-hosted deployment, you can inspect the identities table by checking rows with provider = 'apple' or provider = 'azure' and provider_data->>'iss'. All Apple identities must have an issuer value starting with https://appleid.apple.com/, and all Azure identities must have an issuer value starting with https://login.microsoftonline.com/ or https://sts.windows.net/. Any other issuer values are an indication that this vulnerability was likely exploited.
Impact
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.
As of version 2.185.0 the vulnerability has been patched.
Attack Vector
The attack vector differs slightly for the Apple and Azure providers (steps below) and whether it is on the Supabase platform versus a self-hosted deployment. Prerequisites for both vectors are:
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 (see examples below). 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.
Azure
Apple
Security Recommendations
Immediately update to version 2.185.0 or above if your self-hosted project relies on Apple or Azure authentication. If self-hosting establish a process to continuously and timely update your Auth server to the latest version.
To improve your application's security posture, consider enforcing MFA on all user accounts including verification on all sensitive actions of your application. If that is not possible consider re-authenticating or confirming sensitive data access or actions with your users by sending them an email or SMS message.
When self-hosting, never expose the Auth server directly on the internet. We recommend Auth be placed behind a reverse proxy (like Envoy, nginx, Caddy, Kong, or similar) which should be kept up-to-date.
To audit whether this vulnerability was exploited against your self-hosted deployment, you can inspect the
identitiestable by checking rows withprovider = 'apple'orprovider = 'azure'andprovider_data->>'iss'. All Apple identities must have an issuer value starting withhttps://appleid.apple.com/, and all Azure identities must have an issuer value starting withhttps://login.microsoftonline.com/orhttps://sts.windows.net/. Any other issuer values are an indication that this vulnerability was likely exploited.