[TheGeminon]

I haven’t read the actual report, but I would imagine a scenario like this would be possible:

1. Mallory registers an account for [e-mail] using a password.

2. Alice receives an account activation email, but doesn’t do anything about it.

3. At a later date Alice registers an account on the service using a social login/SSO (e.g. Google, GitHub)

4. Alice properly activates the account (may or may not be required, depending on the service).

5. The service merges the password account together with the SSO account since they have the same email.

6. Mallory can access Alice’s account with their original password from step 1, while Alice continues to use social login, unaware they also have a password set.

[Gigachad]

Took me several reads to fully understand this but it actually is concerning since there is no user error required here. Although it is a little unlikely and hard to pull off

[jobigoud]

> Although it is a little unlikely and hard to pull off

As always with this kind of attack they are not targeting specific individuals, they probably do this to millions of accounts and periodically check if they can login to any.

[xvector]

Don't most services require you to confirm your email? Mallory would be unable to get past step 1

[Gigachad]

Not really. It’s become a design trend to send a confirmation email but then not require it. Part of reducing user signup friction. Then later you might prompt or push the user to confirm or mark users with unconfirmed emails as a higher abuse risk.

[croon]

The way I read it it's dormant (unconfirmed) until Alice signs up, at which point it's implicitly confirmed through SSO.

[n4bz0r]

Where is Bob? What happened to Bob? Has anyone seen Bob lately?

[mikevm]

Bob is a good guy, M(alicious)allory is a bad girl.