Bug: GitHub login flow can silently merge accounts via email reuse without verifying ownership of pre-existing local account

[hariom888]

In apps/backend/src/routes/auth.ts, the GitHub OAuth callback (and the equivalent Google callback) handles the "no userIdentity found" case by looking up existingAccount by email and, if found, attaches the new provider identity to that account:

const existingAccount = await app.prisma.user.findUnique({ where: { email } });

if (existingAccount) {
  await app.prisma.userIdentity.create({
    data: { userId: existingAccount.id, provider: 'github', providerId: githubUser.id.toString() }
  });
  user = existingAccount;
}

For GitHub, email is derived from githubUser.email or, if null, the first primary && verified entry from /user/emails. The verified-email check on GitHub's side is trusted implicitly. However, there's a deeper issue: this account-linking happens with no re-authentication or confirmation step from the existing account owner. Any user who can get GitHub to report a given verified email (e.g. via GitHub's email-visibility settings, or a GitHub account where they've added/verified an email that matches a DevCard user's email — GitHub allows adding emails and they become "verified" once the GitHub-side confirmation email is clicked, which an attacker can do for emails they control or, in cases of stale/abandoned email addresses, emails they've taken over) can have their userIdentity silently attached to an arbitrary pre-existing DevCard account matching that email.

Once linked, that GitHub account becomes a permanent additional login method for the victim's DevCard account (issuing fresh accessToken/refreshToken cookies for existingAccount.id), with no notification email, no audit log entry distinguishable from normal login, and no requirement that the user prove control of the DevCard account being linked (e.g. by being logged in already, or confirming via the original auth method).

This is an account-takeover-via-identity-linking pattern: the trust boundary between "I proved I own this email on GitHub right now" and "therefore I should be granted standing access to whatever DevCard account already used that email" is not validated against the current session state of the DevCard account.

Affected: apps/backend/src/routes/auth.ts — both github/callback and google/callback handlers, in the else branch following the if (identity) check (the existingAccount lookup-and-link block).

[github-actions]

Hi @hariom888,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[hariom888]

/backend

[hariom888]

Understanding: When a user authenticates via a new OAuth provider and no userIdentity row exists for that (provider, providerId) pair, the code falls back to matching by email and silently creates a userIdentity linking the new provider to whatever account owns that email — without any signal that the person currently driving the browser is the same person who controls the existing account. This is the classic "email-based account linking" anti-pattern; it's safe only if the email itself is a strong, currently-verified, non-reusable identity proof, which is not guaranteed across providers/time (email reuse, account recycling, GitHub email visibility/verification quirks).

Affected files: apps/backend/src/routes/auth.ts (github/callback, google/callback — the existingAccount linking blocks), prisma/schema.prisma (UserIdentity model, for any new linking-state fields).

Proposed fix approach: Require an explicit "link account" step gated on the user being already authenticated (i.e. only allow this auto-link path if the request carries a valid session for existingAccount.id, via a "connect another login method" flow rather than the primary login callback). For the primary login callback, when existingAccount is found but no session proves ownership, either (a) reject the login with a "this email is already registered — please log in with your original method and link providers from settings" message, or (b) send a confirmation email to the existing account's address requiring approval before the identity link is created.

Test considerations: Add tests covering: (1) brand-new email → new user created (existing passing case); (2) existing userIdentity for provider+providerId → normal login (existing passing case); (3) email matches an existing account but no prior identity for this provider, with no active session for that account → should now be rejected/require confirmation rather than silently linked (new regression test capturing the fix); (4) the legitimate "connect a second provider while logged in" flow still works via the dedicated linking endpoint.

Requesting this issue be assigned to me under GSSoC'26.

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[Harxhit]

@hariom888 Thanks for the report.

From my understanding, this scenario requires the OAuth provider (GitHub or Google) to return an email address that matches an existing DevCard account and is verified by the provider.

In practice, both GitHub and Google require ownership verification of the email address before it can be returned as a verified email claim. An attacker cannot simply choose an arbitrary user's email and have the provider assert ownership of it.

The described scenario therefore appears to rely on the attacker already controlling the target email account. In that case, the attacker already possesses the primary identity factor associated with the account.

While requiring an additional account-linking confirmation step could be considered a defense-in-depth improvement, I do not currently see this as an account takeover vulnerability in the existing implementation.

If I'm missing a realistic path where a user can obtain a verified GitHub or Google identity for an email address they do not control, please provide a concrete reproduction scenario.