# Rider can forcefully get passenger's order accepted resulting in multiple impacts including PII reveal and more mentioned in the report.

Driver could call /api/setTenderStatus to force-accept a passenger's order and tamper bid price, leaking PII and overcharging.

- Payout: hidden
- Severity: high
- Program: inDrive
- Found by: spongebhav
- Disclosed: 2023-06-28
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1960107
- Library page: https://bugbountylibrary.com/r/h1%3A1960107
- Tags: area:web domain:api impact:integrity impact:pii-leak kind:bounty platform:hackerone sev:high technique:chained vuln:access-control vuln:business-logic

**Target:** REST API endpoints /api/setTenderStatus and /api/driverrequest on terra-*.indriverapp.com
**Root cause:** setTenderStatus lacks authorization binding the status change to the passenger, letting a driver set status=accept on any tender/order. driverrequest also fails to validate the submitted price against allowed range.
**Steps:**
1. Send bid via `/api/driverrequest?...&order_id=X&price=63...` and capture tender_id and order_id
2. Call `/api/setTenderStatus?cid=5957&...&tender_id=T&order_id=X&status=accept` with the driver's token
3. Ride is accepted on behalf of the passenger without their consent
4. Modify `price` in driverrequest to an out-of-range high value to force an inflated bid
**How found:** Observed the driverrequest bid flow and noticed setTenderStatus accepted a status parameter controllable by the driver, then tested flipping status to accept.
**Exploitation:** Driver submits a bid, then replays setTenderStatus with status=accept using the tender/order IDs, forcing acceptance and exposing passenger PII (phone). Combined with price tampering, passenger is tricked into a higher fare. Automatable in real time.
**Escalation:** Chained price-range bypass in driverrequest with forced acceptance to overcharge and harvest PII at scale.
**Insight:** In two-sided marketplaces, watch state-transition endpoints (accept/confirm) for missing actor-role checks — the party that should only propose can often also confirm if the status param is client-controlled.
