Let's Dive into Today's Bug

While testing an application's authentication flow, I found an issue that could lead to full account takeover and eventually lock the real user out of their account.

The root cause was simple: the application allowed account registration with any email address without verifying ownership.

Later, when the real owner signed in using Google OAuth, the system automatically linked both identities based on the email match.

This created a dangerous scenario where an attacker could pre-register a victim's email, wait for the victim to authenticate via Google, and then take control of the same account.

How I Found It

I started by testing the authentication flow as a normal user, focusing on registration, login, and profile settings.

Two key issues stood out:

• Account registration did not require email verification
• Email changes also did not require verification

This raised a simple question:

What happens if someone registers using a victim's email and the victim later logs in with Google OAuth?

That question led directly to the vulnerability.

The Vulnerability

The system treated the email address as the primary identity.

So when the victim logged in using Google OAuth, the application automatically merged both accounts because the email matched.

After that, the attacker retained full access through the original password.

Since email changes were not verified, the attacker could further modify account details and escalate control, disrupting the victim's ability to recover access.

Proof of Concept

1. The attacker registers an account using victim@email.com (no email verification required).
2. Later, the victim logs in using Google OAuth with the same email.
3. The application automatically links both identities, and the victim is unaware that another account now shares control.
4. The attacker logs in using the original password and gains access (at this stage, password reset is still possible for recovery).
5. To escalate to full account takeover and lockout: 5.1 The attacker changes the account email to another address (e.g., Free@Palestine.com) without verification. 5.2 The attacker changes the password, which invalidates the victim's active session.
6. The victim can no longer use password reset since the email has been changed.
7. Finally, when the victim tries to log in again using Google OAuth, access fails due to broken account linking.

At this point, the attacker retains full control of the account while the legitimate user is permanently locked out.

Impact

This issue can lead to:

• Full account takeover
• Permanent user account lockout
• Broken Google OAuth login after email manipulation
• Unauthorized access to sensitive account data and settings
• No reliable recovery path for the legitimate user

Root Cause

The application over-relied on the email address as the identity anchor.

Since emails are mutable, using them for account linking introduces a critical security weakness.

A safer approach is to rely on stable OAuth provider identifiers instead of email matching.

Recommendation

To remediate this issue:

• Require email verification before activating accounts
• Avoid automatic account merging based only on email
• Use Google's stable OAuth identifier (sub) for identity mapping
• Require verification for all email change operations
• Invalidate all active sessions after any identity-related change

Takeaway

Small authentication flaws can compound quickly — when unverified account creation meets automatic Google OAuth linking, it can escalate into full account takeover and complete user lockout.

Report Status

This report was marked as a duplicate :)

Let's Connect: x account || linkedin account

Don't forget to follow me on this medium account :)

"سُبْحَانَكَ اللَّهُمَّ وَبِحَمْدِكَ ، أَشْهَدُ أَنْ لا إِلَهَ إِلا أَنْتَ ، أَسْتَغْفِرُكَ وَأَتُوبُ إِلَيْكَ"