# phone number exposure for riders/drivers given email/uuid

Uber passwordless-signup endpoint returned the victim's phoneNumberE164 in an error response when replaying a request with their UUID and state SIGN_IN.

- Payout: hidden
- Severity: medium
- Program: Uber
- Found by: vijay_kumar
- Disclosed: 2017-06-02
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/225243
- Library page: https://bugbountylibrary.com/r/h1%3A225243
- Tags: area:web domain:api impact:pii-leak kind:bounty platform:hackerone sev:medium technique:source-review vuln:access-control vuln:info-disclosure

**Target:** POST /rt/users/passwordless-signup on cn-dca1.uber.com
**Root cause:** The passwordless-signup state machine, when given state SIGN_IN with a victim's loginId (UUID), fails validation but still includes the resolved account's phoneNumberE164 in the error response body.
**Steps:**
1. Send `POST /rt/users/passwordless-signup` with `loginId` set to victim UUID, `state: "NOT_STARTED"`, `userWorkflow: "PASSWORDLESS_SIGNUP"`; response returns serverState SIGN_IN.
2. Replay same request with `state: "SIGN_IN"` and the victim UUID as `loginId`.
3. Response errorCode INVALID_REQUEST includes `"phoneNumberE164": "+919899665409"` — the victim's phone number.
**How found:** Researcher probed the passwordless-signup state machine, noticed the first NOT_STARTED request transitioned serverState to SIGN_IN, then forced state SIGN_IN to trigger an error path that leaked account data.
**Exploitation:** Attacker who knows a rider/driver UUID (or email) submits it as loginId with state SIGN_IN to the passwordless-signup endpoint; the error response discloses the account's E.164 phone number, enabling privacy breach and further social-engineering/SIM-swap targeting.
**Insight:** On multi-step auth/signup state machines, replaying a later state (e.g. SIGN_IN) with an identifier from an earlier step can hit error branches that echo resolved account fields like phone/email; fuzz state transitions with victim identifiers.