"اللَّهُمَّ انْفَعْنِي بِمَا عَلَّمْتَنِي، وَعَلِّمْنِي مَا يَنْفَعُنِي، وَزِدْنِي عِلْمًا"

Hello everyone! I'm "Abdurrahman", and I'm excited to share my first write-up with you: -

# First of all, this program is the kind of programs where each user has their own organization, which may contain some teams. A company admin and team admins can add other people with different role

• Org Admin
• Team Admin
• Member
• Guest

#These programs are the best for searching about "BAC" 🔥

- So, I tried many times searching for vertical privilege escalation, but my efforts didn't pay off.

Then I thought, "what if" the problem isn't in the difference of roles within the same organization?

-> After that, I kept trying to get into more than one organization in my search for a way to make the system do something unusual.

# And now it's time for me to start changing the IDs.

And in this case, I like to rely on these two methods.

-> As example If I have Organization1 let's call it A, and another one called B

1- If you make a request in Org A, try to change id of the Org to the id of Org B.

2- If you make a request in org A, try to change the token of the user who responsible for the request to a user from Org B

#They look similar, but the core difference is in identity:

• Changing the org ID → You're the same user and token, just pointing the request to another organization's resource. That's an authorization / IDOR issue (improper ownership check).
• Changing the token to a user from org B → You're actually changing identity and acting as a different user. That's a context isolation or token misuse issue.

In short: 👉 First = resource validation problem. 👉 Second = identity validation problem.

-> And after some experiments, I discovered something that really caught my eye: -

# If the Org admin or team admin try to add a new member to their Org and change the request method from POST to GET

-> SO, I receive a list of all members of the org containing "sensitive metadata fields"

# Then "I thought to myself, what if…"

-> What happens if the person who made this request is not from the organization itself? Is it possible for me to receive complete Metadata on all the organization's members?

* I tried from organization A to add a new member and change the organization's ID to B.

-> but it returns "unauthorized access" 🤦🤦‍♂️🤦‍♂️

# It suddenly hit me — does the user who made the request from organization A need to also be part of organization B to be authorized?

then I tried again and -> "And here was the shock"

# I receive a list of all members of the org containing "sensitive metadata fields" 💀💀💀

Example response snippet for each: -

{
  "name": "victim",
  "id": "3458764637478925574",
  "type": "USER",
  "cardHolder": true,
  "userGroupsNumber": 0,
  "email": "victim.01230123@gmail.com",
  "license": "FULL",
  "picture": {
    "isAutoGenerated": true,
    "id": "3458764514998066774",
    "image": "https://cdn.example.com/avatars/3458764514998066774"
  },
  "accountsNumber": 2,
  "lastActiveDate": "2025-08-17T11:16:30.444Z",
  "licenseAssignmentDate": "2025-08-16T05:30:00.725Z",
  "addingDate": "2025-08-16T05:30:00.725Z",
  "role": "ORGANIZATION_INTERNAL_ADMIN"
}

Summary

This is a classic IDOR caused by missing authorization checks on an API parameter. While the UI hides this data, the backend still returns it to any user who manipulates the request — leading to cross-organization data leakage.

# Anyway, the issue turned out to be a "duplicate" and was classified as "Medium". I had thought it would be more severe, but I realized it was rated that way because an attacker would, at minimum, have to be a member of the organization where the exposure occurs.

لو وصلت لحد هنا ارجو انك تكتب رأيك عن الرايتاب أو لو في اي نصايح

If you have reached this point, I hope you write your opinion about Writeup and any advice you may have.

< والله المستعان >