Impact
Under a very specific set of circumstances, users logging in to Gotrue would inadvertently masquerade a different user ("U0"). U0 is a single specific user per auth provider for a given Gotrue instance; it is the first user that logged in using the provider whilst triggering the bug.
On the hosted Supabase Cloud service, these additional permissions granted these users access to the organizations and corresponding projects belonging to U0.
On other instances of Gotrue, the permissions granted could expose other user-scoped resources belonging to U0.
Affected Versions
Gotrue versions 2.1.11 through 2.5.6 are impacted.
The latest version of Gotrue (2.5.7) contains the patch, and it is recommended that you upgrade to it.
Remediation
The Supabase cloud platform and all projects hosted on it have already been patched and are no longer vulnerable to this issue. It is recommended that self-hosted setups upgrade to the latest Gotrue version.
Details
When a user logs into Gotrue via an external provider (e.g. Github), we uniquely identify them using a tuple of the provider, and the unique ID each provider assigns to each of their users. As an example, (github, 456) would identify in Gotrue the Github user with the ID 456.
This bug gets triggered when an external provider provides a valid json response within the context of a particular flavour of failures when querying them about a user's details. While http failures (or a missing, or invalid json response) should've [correctly] caused Gotrue to bail, Gotrue incorrectly signs in the user while identifying them as e.g. (provider_name, wrong_provider_id). This is due to a bug spotted where non-2xx status codes were not being handled properly.
The first user to trigger this condition would go through an otherwise normal workflow, even though they're identified by an incorrectly-assigned ID. Subsequent users that trigger this condition, however, would essentially [inadvertently] masquerade as U0, and would have access to U0's resources.
References
For more information
If you have any questions or comments about this advisory:
Impact
Under a very specific set of circumstances, users logging in to Gotrue would inadvertently masquerade a different user ("U0"). U0 is a single specific user per auth provider for a given Gotrue instance; it is the first user that logged in using the provider whilst triggering the bug.
On the hosted Supabase Cloud service, these additional permissions granted these users access to the organizations and corresponding projects belonging to U0.
On other instances of Gotrue, the permissions granted could expose other user-scoped resources belonging to U0.
Affected Versions
Gotrue versions 2.1.11 through 2.5.6 are impacted.
The latest version of Gotrue (2.5.7) contains the patch, and it is recommended that you upgrade to it.
Remediation
The Supabase cloud platform and all projects hosted on it have already been patched and are no longer vulnerable to this issue. It is recommended that self-hosted setups upgrade to the latest Gotrue version.
Details
When a user logs into Gotrue via an external provider (e.g. Github), we uniquely identify them using a tuple of the provider, and the unique ID each provider assigns to each of their users. As an example,
(github, 456)would identify in Gotrue the Github user with the ID 456.This bug gets triggered when an external provider provides a valid json response within the context of a particular flavour of failures when querying them about a user's details. While http failures (or a missing, or invalid json response) should've [correctly] caused Gotrue to bail, Gotrue incorrectly signs in the user while identifying them as e.g.
(provider_name, wrong_provider_id). This is due to a bug spotted where non-2xx status codes were not being handled properly.The first user to trigger this condition would go through an otherwise normal workflow, even though they're identified by an incorrectly-assigned ID. Subsequent users that trigger this condition, however, would essentially [inadvertently] masquerade as U0, and would have access to U0's resources.
References
For more information
If you have any questions or comments about this advisory: