IDOR to add secondary users to any PayPal business account

One missing authorization check on a PayPal business-account endpoint let any authenticated user silently add themselves - or anyone else - as a secondary user on accounts they had no rights to.

The Target

PayPal's business accounts support a multi-user model: a primary account holder can invite secondary users (employees, accountants, etc.) and grant them specific permissions. The invite/add secondary-user flow was exposed through an API endpoint that accepted an account or user identifier in the request body.

The Vulnerability

The bug was an Insecure Direct Object Reference (IDOR) - a subclass of broken access control. The endpoint accepted a user-supplied identifier representing the target business account, processed the "add secondary user" action, and never verified that the authenticated caller owned or had rights to modify that account.

In Linux permissions terms, this is the equivalent of a chmod or chown command that skips the ownership check: any process could rewrite permissions on any file simply by naming it. The object (the business account) was directly referenced by its ID, and the server trusted that ID without asking "does this caller have the right to act on it?"

How It Was Found

The researcher intercepted the API request made when legitimately adding a secondary user to their own test business account, identified the account identifier field in the request, and swapped it for the identifier of a different business account. The server accepted the modified request and added the secondary user to the victim account.

An illustrative request showing the parameter swap:

POST /businessmanage/users/addUser HTTP/1.1
Host: www.paypal.com
Authorization: Bearer <attacker-session-token>
Content-Type: application/json
 
{
  "accountId": "VICTIM_BUSINESS_ACCOUNT_ID",
  "userEmail": "attacker@evil.com",
  "permissions": ["SEND_MONEY", "VIEW_TRANSACTIONS"]
}

By replacing the accountId with the ID of any other PayPal business account, the attacker could add their own email as a secondary user - with whatever permissions the API allowed.

Impact

• An attacker could add themselves as a secondary user on any PayPal business account worldwide.
• With secondary-user access, depending on assigned permissions: view transaction history, initiate money transfers, download financial statements, or access sensitive merchant data.
• The attack is silent - no notification required a victim to approve the invite if the endpoint skipped that check.
• This affects business accounts, meaning merchant and corporate accounts with potentially large balances and sensitive customer data.

PayPal awarded $10,500 for this report, reflecting the high severity of unauthorized financial account access.

The Fix

Every API endpoint that acts on an owned resource must include a server-side ownership or authorization check - before performing the action:

1. Tie every object-level action to the authenticated principal. When processing "add user to account X", the backend must confirm the session token belongs to someone authorized to manage account X.
2. Do not trust client-supplied IDs as proof of ownership. The server should derive the account identity from the authenticated session, not from request parameters.
3. Apply the same check to reads, writes, and deletes. IDOR vulnerabilities appear in every HTTP verb, not just GET requests.
4. Use authorization middleware consistently - a centralized policy check so no endpoint can accidentally skip it.

What You Can Learn

• IDOR is a permissions failure at the application layer. Just like a world-writable file in Linux (chmod 777) lets any user overwrite it, an IDOR lets any API caller overwrite or act on any object by its ID.
• Ownership must be validated server-side, every time. Client-supplied identifiers are untrusted input. The server must independently confirm the requester's rights.
• Business logic endpoints are high-value IDOR targets. "Add user," "transfer money," and "change role" operations carry more impact than simple read IDORs - look for them specifically.
• Enumerable IDs make IDORs trivially exploitable. Sequential integers, short UUIDs, or predictable patterns mean an attacker can iterate targets without needing insider knowledge.
• Testing is straightforward with two accounts. Create two test accounts, perform an action on account A, then replay the request substituting account B's ID. If it succeeds, you have an IDOR.