Skip to content
Llorenç Romà

Type to search…

↑↓to navigate
Esc

Little rant about Pre-Account Takeover

Pre-Account Takeover, the forgotten one.

Security Research3min read

I kept finding the same bug in different places:

  1. Register with someone else’s email address using the password flow.
  2. Do not verify the email address.
  3. Wait for the real owner to register with Google SSO.
  4. Log out.
  5. Log back in with the password set before the real user ever arrived.

In the bad implementations, it works. The legitimate user proves ownership through Google, and the application silently activates a password that was created by someone else earlier.

And many places classify it as account squatting. That label is convenient, but it is wrong when the attacker ends up with a valid login method on the victim’s account.

The frustrating part is that multiple sites handle it correctly, meaning the ones that do not are making a fixable authentication mistake.

I understand why this issue looks boring at first.

An attacker creates an account with an email address they do not control. The account is unverified. The confirmation email goes to the real inbox (sometimes not). The attacker cannot click it. Nothing dramatic happens.

If the story ended there, I would agree with the usual triage response: account squatting, low impact, maybe annoying but not critical.

But that is not where the story ends.

The real problem appears later, when the actual owner of the email address registers normally. They choose Google or any other SSO option. Google confirms the email address. The application decides that this is the same account. Then, instead of treating the old password as untrusted baggage, it keeps it alive.

At that point, the attacker is no longer just squatting. They have a working credential.

That is the line that should matter.

The test is simple enough that it became part of my normal authentication checklist.

Find a site that supports both:

  • email and password registration,
  • Google SSO registration or login.

Then test the account transition:

  1. Start with a fresh target email address (victim email)
  2. Attacker register using the password flow.
  3. Set an attacker-controlled password.
  4. Stop before email verification, or leave the verification code unused.
  5. In a separate browser, [the victim] registers or logs in with Google SSO as the real owner of that email.
  6. Log out.
  7. Try to log in using the victim email and the attacker-controlled password.

The only question is:

Does the attacker’s original password opens the same account after SSO sign-in

If yes, the site has turned an unverified credential into a valid login method because a different authentication provider later proved ownership of the email address.

That is the bug.

I tested enough sites to see multiple safe outcomes:

  • The password login method was removed after Google SSO registration.
  • The account became Google-only until the user explicitly set a password.
  • Password login required a an email verification code in addition to the password every time.
  • The SSO account was linked without trusting credentials created before verification.

These are not theoretical recommendations. They are real behaviors implemented by real services.

So when another site leaves the attacker-set password active, it is hard to accept that as a harmless product decision. Other teams solved the same problem. The broken behavior is not inevitable.

I’m not saying every pre-registration report is a serious vulnerability. Sometimes someone has just claimed an email address they don’t own, and that’s as far as it goes.

But if the real owner signs up with Google and the password I set before they arrived still lets me into their account, come on. Calling it “account squatting” doesn’t make that access disappear.