# Login to any account with the emailaddress

Zomato's Google login endpoint issued a valid access token for any account given only the victim's email address, enabling full account takeover.

- Payout: $1,000
- Severity: high
- Program: Eternal
- Credited: gerben_javado
- Disclosed: 2017-08-17
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/245408
- Library page: https://bugbountylibrary.com/r/h1%3A245408
- Tags: domain:api domain:mobile impact:ato kind:bounty platform:hackerone sev:high tech:oauth technique:param-pollution vuln:account-takeover vuln:auth-bypass

**Target:** Mobile app auth API endpoint /v2/auth.json (Google login flow)
**Root cause:** The Google OAuth login handler trusted a client-supplied email parameter and issued an access token without verifying the Google OAuth token or any proof of identity.
**Steps:**
1. Intercept the mobile app's Google login request to `POST /v2/auth.json?isGoogle=true`
2. Strip parameters one by one, leaving only `email=email@example.com`
3. Send `POST /v2/auth.json?isGoogle=true` with `X-API-Key` header and body `email=victim@example.com`
4. Receive a valid access token for the victim account
**How found:** Focused on the mobile app for server-side bugs; noticed the Google login request sent much more data than just the OAuth token, so stripped parameters one by one until only the email remained and login still succeeded.
**Exploitation:** Attacker sends a single POST to /v2/auth.json?isGoogle=true with the victim's email and the app's X-API-Key, receiving a valid access token granting full access to the victim's Zomato account, no user interaction required.
**Insight:** On mobile OAuth flows, strip the request down to individual fields to test whether the server actually validates the OAuth token or just trusts a client-supplied identifier like email.