# Paypal bug $10K - All Secondary users account takeover leads to unauthorized money transfer from paypal business accounts

IDOR on PayPal business secondary-user privilege API let an attacker enumerate user IDs, list any secondary user, reset their password, and transfer funds.

- Payout: $10,000
- Severity: critical
- Program: Paypal
- Credited: Mohd haji
- Disclosed: 2019-07-30
- Write-up quality: 6/10
- Original: https://web.archive.org/web/20210124152317/https://whitehathaji.blogspot.com/2019/07/paypal-bug-10k-all-secondary-users.html
- Library page: https://bugbountylibrary.com/r/blog%3Aweb-archive-org-web-20210124152317-https-whitehathaji-blogspot-com-2019-07-paypal-bug-10k-all-secondary-users-html
- Tags: domain:web impact:ato impact:funds-loss kind:bounty platform:blog sev:critical tech:rest technique:recon vuln:access-control vuln:account-takeover vuln:idor

**Target:** PayPal business account secondary-user management API (PUT /businessmanage/users/api/v1/users)
**Root cause:** The privilege-edit endpoint trusted a client-supplied secondary-user account id without verifying it belonged to the caller's business account, and the id was a small sequential integer.
**Steps:**
1. Create two business accounts: victim@gmail.com (secondary user victim1234) and attacker@gmail.com (secondary user attacker1234).
2. As attacker, open the secondary user page and capture the permission-edit request: `PUT /businessmanage/users/api/v1/users` with body `[{"id":"1660971175791245038","accessPoint":{"privileges":["MANUAL_REFERENCE_TXN","VIEW_CUSTOMERS","SEND_MONEY"],"id":"4446113495","accounts":["attacker@gmail.com"]},"roleID":0,"roleName":"CUSTOM","privilegeChanged":true,...}]`.
3. Replace the first `id` with a dummy value and set the second `id` (accessPoint.id) to a victim's sequential id, e.g. `44613496`.
4. Enumerate accessPoint.id from 44613495 to 44613999; each victim secondary user appears in the attacker's Manage Users list.
5. Reset the victim secondary user's password via Manage Users to take over the account.
6. Log in as the victim secondary user holding the 'Transfer Money' privilege and transfer funds from the victim business account to the attacker.
**How found:** Author noticed the privilege-edit PUT request contained a second numeric id (accessPoint.id) distinct from the user id; testing a dummy first id and observing the second id controlled which user was affected revealed it was enumerable and not scoped to the caller.
**Exploitation:** Attacker with any business account enumerates sequential secondary-user ids via the privilege-edit API, adds victims to their Manage Users view, resets their passwords, and logs in as secondary users with SEND_MONEY privilege to move funds out of victim business accounts.
**Escalation:** IDOR on user listing chained to password reset (account takeover) and then to unauthorized money transfer via the SEND_MONEY privilege.
**Insight:** In multi-tenant management APIs, the object id inside nested objects (e.g. accessPoint.id) is often authorized separately from the top-level id; swap nested ids and check whether sequential integers leak cross-tenant objects.