# Account takeover w/o interaction for a user that doesn't have 2fa enabled via 2fa linking and improper auth at /api/2fa/verify

2FA linking and verify endpoints trusted a client-supplied user ID, letting an attacker bind 2FA to a victim account and log in as them.

- Payout: hidden
- Severity: medium
- Program: Helium
- Found by: w2w
- Disclosed: 2020-07-26
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/810880
- Library page: https://bugbountylibrary.com/r/h1%3A810880
- Tags: area:web domain:web impact:ato kind:bounty platform:hackerone sev:medium tech:rest vuln:account-takeover vuln:auth-bypass vuln:mfa-bypass

**Target:** /api/2fa and /api/2fa/verify endpoints
**Root cause:** The 2FA link and verify endpoints authorized actions based solely on a user-supplied ID in the request body rather than the authenticated session, so any user could bind or verify 2FA for another account.
**Steps:**
1. Register user1 at console.helium.com, skip 2FA, note user1's ID.
2. Register user2, send 2FA link request to `/api/2fa` with user1's ID substituted in the body.
3. 2FA is now enabled on user1's account.
4. Send `/api/2fa/verify` with a valid code and user1's ID, no session token needed.
5. Attacker is logged in as user1.
**How found:** Noticed the 2FA endpoints accepted a user ID from the request body and tested substituting another account's ID, observing the link and verify succeeded without matching session context.
**Exploitation:** Attacker substitutes victim's known user ID into the 2FA link request to bind their own authenticator to the victim account, then calls /api/2fa/verify with the valid code and victim ID without any session cookie, authenticating as the victim.
**Insight:** On 2FA enrollment/verification endpoints, check whether the account identity comes from the request body ID rather than the session; swapping in a victim's ID often binds your authenticator to their account.