The OAuth callback handler in Authorizer links incoming OAuth identities to existing user accounts by matching email addresses without verifying that the existing account's email was verified by its original owner. If an attacker pre-registers an account with a victim's email address but does not verify it, and the victim later logs in via OAuth, the system links the OAuth identity to the attacker's unverified account. The email is automatically marked as verified, the OAuth provider is appended to the signup methods, but the attacker's original password remains valid and is not invalidated or cleared. This allows the attacker persistent password-based access to the victim's account without any further interaction from the victim, constituting a zero-click account takeover. The vulnerability affects all OAuth providers configured in Authorizer. The root cause is a trust boundary violation where the system trusts the OAuth provider's email verification but incorrectly trusts the password set by the unverified attacker. The suggested fix is to verify that the existing account's email is verified before linking OAuth identities and to invalidate existing passwords or require re-authentication when linking new OAuth identities.

This vulnerability allows full account takeover for any user who logs in via OAuth if an attacker has pre-registered an unverified account with the victim's email. The attacker maintains persistent password-based access even if the victim changes OAuth providers or revokes OAuth access. The victim has no indication that their account was pre-staged by the attacker. All data created by the victim after OAuth login is accessible to the attacker. The issue affects every OAuth provider configured in Authorizer, including Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, and Microsoft.

A patch is available for this vulnerability. The vendor should be consulted for the official fix. The recommended remediation is to verify that the existing account's email is verified before linking an OAuth identity. If the email is not verified, the system should reject the login, create a new separate account, or delete the unverified account before creating a fresh one for the OAuth user. Additionally, when linking a new OAuth identity, any existing password on the account should be invalidated or the user should be required to re-authenticate via the original method. These steps prevent attackers from maintaining unauthorized password access after OAuth linking.