Pre-Account Takeover: a simple bug that still works too often

Technical log on a redacted Pre-ATO finding. This is one of the most common logic flaws in modern web apps.

The Concept

A Pre-Account Takeover (Pre-ATO) is a "race" against the victim. You create an account using their email address before they do. If the application handles social logins (SSO) poorly, you can maintain access even after the real owner "claims" the account.

The Workflow

I found this on a major e-commerce platform. The site offered two ways to sign up: classic email/password and "Sign in with Google."

The bug started in a part of the registration flow people often skip testing properly: the post-Google step where the site shows your email and asks for a few extra details before finishing account creation.

1. The Setup

I log in with Google using an email I control. After that, the site drops me into a profile completion form. The email field is there, but it is disabled in the browser.

That is already interesting. When I see a disabled field during registration or SSO onboarding, I usually try editing it anyway, either by removing the attribute in DevTools or just intercepting the request. In this case I removed disabled="true" from the email field and changed it to an unregistered victim address.

The backend accepted it.

2. The Victim's Action

Now the victim comes later with that same email. At that point they cannot register normally anymore because the address is already taken. They can still recover the account with the usual password reset flow, or just try to sign in the way a normal user would.

3. The Logic Flaw

The application trusts the Google identity that was linked earlier and never really cleans up the ownership problem it created by accepting that email change. So the victim ends up using the account tied to their address, but the original Google linkage is still mine.

The victim is logged in. Everything looks normal to them.

Why it is dangerous

The victim thinks they have a fresh, secure account. In reality, they are sharing it with me.

Since I set the original password, I can still log in using the email/password form while the victim uses SSO. We are both authenticated to the same session. I can wait for them to add a credit card, change their shipping address, or read their order history. It is a silent, persistent back-door.

What I actually check for in flows like this

Nothing fancy here. This kind of bug often comes from small frontend assumptions.

• Disabled fields during signup, OAuth onboarding, or profile completion
• Email fields shown after social login
• Forms that trust what is in the DOM instead of revalidating on the server
• "Email already exists" states after changing an address somewhere else
• Password reset after an email was changed in a weird flow
• Whether an existing SSO link survives account recovery or ownership changes

Also check profile settings after logging in with SSO. Sometimes the email field is disabled only in the frontend. Just enable it in DevTools and try editing it.

The Fix

The fix is simple but often overlooked. You should never merge a verified SSO identity with an unverified local account.

If an account already exists with that email, the app should:

1. Force the user to verify the existing account via a link sent to their email.
2. Or, invalidate the old password and force a reset before allowing the SSO link.

Disclosure

I would call this an easy bug. Most of the time it is medium or even low depending on the platform. In some specific cases it can go higher, but usually it is just one of those logic issues people miss because the flow looks normal.

The program accepted the report, patched the logic, and paid €200.

---

If a registration flow shows your Google email in a disabled field and asks for extra info, try to enable that field in DevTools and change the email to a victim's address. If the backend accepts it, you've probably just found a Pre-ATO.