# <![CDATA[Permanent account takeover on Yahoo's Small Business platform]]>

Password reset trusted a client-supplied uuid parameter not bound to the sign token, letting an attacker reset any account's password by swapping the uuid.

- Payout: $4,000
- Severity: critical
- Program: Yahoo Luminate
- Credited: Sam Curry
- Disclosed: 2017-06-25
- Write-up quality: 7/10
- Original: https://samcurry.net/permanent-account-takeover-on-yahoo-small-business
- Library page: https://bugbountylibrary.com/r/blog%3Asamcurry-net-permanent-account-takeover-on-yahoo-small-business
- Tags: domain:web impact:ato kind:research platform:research sev:critical technique:param-pollution technique:source-review vuln:account-takeover vuln:auth-bypass

**Target:** Password reset endpoint (login.luminate.com /passwordreset)
**Root cause:** The password reset handler accepted a client-controlled uuid identifying the account to reset, and did not verify that the uuid matched the account the sign token was issued for.
**Steps:**
1. Request reset for attacker@attacker.com via `POST /forgotpassword` with `email=attacker@attacker.com`
2. Receive reset link with `sign=` token and hidden `uuid` for attacker account
3. Open reset form, submit `POST /passwordreset` with `password=...&cpassword=...&uuid=<victim_uuid>&sign=<attacker_sign>&email=...`
4. Intercept in Burp and replace `uuid` with victim's UUID (e.g. `6491c80b-2850-4d9c-9061-73a6122b3dca`)
5. Victim password is reset; log in as victim
**How found:** Noticed the reset POST carried unnecessary client-controlled parameters (email, uuid) alongside the sign token; hypothesized uuid was the account identifier and tested whether it was validated against sign by swapping it to a victim UUID.
**Exploitation:** Attacker creates own account, obtains a valid sign token, then swaps the uuid parameter to the victim's UUID in the reset POST. Server resets the victim's password because uuid is not bound to sign. Reusable indefinitely if victim UUID known.
**Escalation:** Permanent takeover: same UUID can be reused repeatedly to reset password and lock out the legitimate owner.
**Insight:** When a reset/verification flow carries both a secret token and an identifier (uuid/email/user id), test whether the identifier is actually bound to the token by mixing a token from your own account with a victim's identifier.
