Account takeover through an unbound email-change link

The hypothesis

Email changes often require a link sent to the new address. I wanted to know what the link was bound to: the account that requested the change, the browser session that opened it, or only the new email address.

The test

1. Create separate attacker and victim accounts.
2. From the attacker account, request an email change to an address you control.
3. Open the confirmation link while signed in as the victim.

On the affected application, the victim account’s email changed. The confirmation token described the new address, but the server applied it to whichever authenticated account opened the link.

Impact

Changing the victim’s email could move password recovery and other account messages to an attacker-controlled address, leading to account takeover. The underlying issue was missing binding between the confirmation token and the account that initiated the change.

Redacted private vulnerability report demonstrating an email-change account takeover

Disclosure timeline

• 24 October 2021: report submitted.
• 26 October 2021: report triaged and rewarded as Critical.

I also shared the testing idea in a public X thread after disclosure.

Takeaway

For every action link, test it from another account and a clean session. A secure token must authorize one specific action for one specific account, and the server must verify that binding before applying the change.