Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts

The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).

Root Cause

In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:

Line 125: The existing user is looked up by email:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))

Line 164: The OAuth user object is replaced with the existing user:

user = existingUser

Lines 173-176: The OAuth provider is appended to the existing user's signup methods:

signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
    signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod

Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:

if user.EmailVerifiedAt == nil {
    now := time.Now().Unix()
    user.EmailVerifiedAt = &now
}

Line 219: The merged user is saved to the database:

user, err = h.StorageProvider.UpdateUser(ctx, user)

At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.

Attack Chain

1. Attacker signs up with [email protected] using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with EmailVerifiedAt = nil.

2. Some time later, the real owner of [email protected] logs in via Google OAuth (a completely normal action).

3. The OAuth callback at line 125 finds the attacker's existing account by email.

4. At line 164, the Google OAuth identity is linked to the attacker's account.

5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).

6. At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.

7. The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.