IDOR Leading to Account Takeover via Email Reassignment

A credit bureau's consumer-facing portal had a user profile update endpoint that failed to validate ownership. An attacker could modify the request to change another user's registered email address to one they controlled, then use the standard password recovery flow to take over the account. The combination of a straightforward IDOR with the platform's own password reset mechanism turned a profile update bug into a full account takeover chain.

The Target

The target was a consumer-facing portal operated by a major credit bureau. The platform allowed consumers to view their credit reports, manage their personal data, and interact with credit-related services. Given the nature of the business (credit data, personal financial information, identity verification) the sensitivity of user accounts on this platform was exceptionally high.

The portal exposed a REST API that handled all user operations, including profile updates, data retrieval, and authentication flows. Users authenticated via bearer tokens and could manage their account details through a dashboard.

Discovery: Profile Update Endpoints Are Goldmines

Profile update endpoints are goldmines for access control testing. They typically accept multiple user-controlled fields (name, email, phone, address) and modify the user record directly. The security question is always the same: does the server determine which user to update based on the authentication token, or based on a parameter the client supplies?

We started by creating a test account on the platform and navigating to the profile management section. The "update my data" action triggered a POST request to /api/v1/user/update with a JSON body containing the user's profile fields.

The first thing we tested was whether changing our own email to another user's email would be accepted. It was. No verification email, no confirmation step. The server simply updated the email field on our account. That was interesting, but not yet an account takeover.

Then we tested the other direction: could we change someone else's email address? We modified the email field in the request body to point at a different user's account, and set a secondary email field to an address we controlled. We sent the request with our own bearer token.

It worked.

The server did not validate that the email being modified belonged to the authenticated user. Instead, it appeared to use the email field in the request body as a lookup key to identify the target user record, then applied the updates (including the secondary email) to that record.

Before arriving at this finding, we tested a few things that did not pan out. We tried injecting additional fields into the request to see if we could modify role or privilege attributes, but the server ignored unknown fields. We also tested whether the bearer token was tied to a specific user ID in a way that would prevent cross-account modification. It was not.

Exploitation: Two Requests to Account Takeover

The exploitation chain was clean and required only two steps:

Step 1: Modify the victim's secondary email

POST /api/v1/user/update HTTP/1.1
Host: [REDACTED]
Authorization: Bearer [ATTACKER_TOKEN]
Content-Type: application/json
{
  "firstName": "unchanged",
  "email": "victim@example.com",
  "secondEmail": "attacker-controlled@attacker.com",
  "address": "unchanged",
  "primaryPhone": null,
  "mobilePhone": null
}

POST /api/v1/user/update HTTP/1.1
Host: [REDACTED]
Authorization: Bearer [ATTACKER_TOKEN]
Content-Type: application/json
{
  "firstName": "unchanged",
  "email": "victim@example.com",
  "secondEmail": "attacker-controlled@attacker.com",
  "address": "unchanged",
  "primaryPhone": null,
  "mobilePhone": null
}

The server returned a success response. At this point, the victim's account record now had the attacker's email address registered as the secondary contact email.

Step 2: Trigger password recovery

The attacker navigated to the platform's password recovery page and initiated a reset for the victim's account. The platform sent the recovery credentials to all registered email addresses on the account, including the secondary email that the attacker had just set.

The attacker received the recovery email at their controlled address, reset the victim's password, and gained full access to the account.

The entire chain required:

• One authenticated request (with the attacker's own valid token)
• Knowledge of the victim's email address
• No interaction from the victim

The victim would not receive any notification that their secondary email had been changed. They might notice a password reset email they did not request, but by then the attacker would already have access.

Root Cause Analysis

There were two distinct failures that combined to create this vulnerability:

Failure 1: Missing ownership validation on the update endpoint. The server used the email field in the request body to identify which user record to modify, rather than deriving the target user from the authentication token. This meant any authenticated user could modify any other user's profile by supplying their email address. This is a textbook Insecure Direct Object Reference: the user-supplied identifier (email) was trusted without verifying that the authenticated user had permission to modify that record.

Failure 2: No verification on secondary email changes. When a secondary email was added or changed, the server did not send a verification email to confirm the new address was owned by the account holder. This meant an attacker could silently attach their own email to another user's account without any notification or confirmation flow.

Either failure alone would have been a significant finding. Together, they created a trivially exploitable account takeover chain. The IDOR provided the ability to modify other users' records, and the lack of email verification ensured the modification went undetected and could be leveraged for password recovery.

The API appeared to follow a pattern where the email field served dual duty as both a piece of user data and a record identifier. This is a dangerous design pattern: mutable user data should never be used as the primary key for authorization decisions. The authenticated user's identity should be derived exclusively from the session or token, never from request body parameters.

Remediation Guidance

1. Derive the target user from the authentication token. The update endpoint must identify which user record to modify based solely on the authenticated session, never from a client-supplied parameter. The bearer token should map to a user ID server-side, and that ID should be the only one used for the update operation.
2. Require email verification for contact changes. Any change to primary or secondary email addresses must trigger a verification flow. The new email should not be active on the account until the recipient confirms ownership by clicking a verification link.
3. Notify users of profile changes. When any profile field is modified, send a notification to the user's existing verified email addresses. This provides an early warning if an attacker manages to modify the account.
4. Separate data fields from identifiers. Do not use mutable user data (email, phone) as record identifiers in API operations. Use immutable internal IDs that are not user-controllable.
5. Implement rate limiting and anomaly detection on the update endpoint. Rapid profile changes across multiple accounts from a single token should trigger alerts.
6. Audit the password recovery flow. The recovery flow should only send reset links to the primary verified email, not to recently added or unverified secondary addresses.

Impact

CVSS Score: 9.1 (Critical)

This vulnerability allowed complete account takeover of any user on the platform. Given the target was a credit bureau's consumer portal, the impact was severe:

• Access to credit data. An attacker could view the victim's full credit report, including financial history, outstanding debts, and credit scores.
• Identity theft enablement. Credit bureau profiles contain the exact personal information needed for identity theft: full legal name, national ID numbers, addresses, phone numbers, and financial relationships.
• Mass exploitation potential. The attack required only the victim's email address, making it scalable. An attacker could automate the process to take over accounts in bulk.
• Lateral impact. The API served multiple consumer-facing services in the region. Account takeover on this platform could cascade to any service sharing the same identity backend.
• Regulatory exposure. Credit bureaus operate under strict data protection regulations. Unauthorized access to credit data at scale would constitute a significant regulatory incident.

The simplicity of the exploitation (two HTTP requests and a password reset) combined with the extreme sensitivity of the data made this one of the highest-impact findings in this engagement.

The Takeaway

IDOR vulnerabilities are often dismissed as "just" parameter tampering, but when they occur on endpoints that modify account ownership attributes (email, phone, recovery mechanisms) they become account takeover primitives. The lesson here is not just to validate ownership on update endpoints, but to think about what each modifiable field enables. An email field is not just a piece of data. It is a key to the account recovery flow. Protecting it requires the same rigor as protecting the password itself.

The fix for this class of bug is straightforward. Finding it is the hard part, and that is where manual, attacker-driven testing earns its keep. Talk to us.

This finding was responsibly disclosed through the organization's authorized security program and has been fully remediated.

Bounty: $4000

Damian Gambacorta is the Founder & CEO of OliveX Security, a boutique offensive security consultancy specializing in application security for enterprise environments.