Sometimes… it's about changing one ID.

In this write-up, I'll explain — step by step — how I discovered a critical Broken Access Control vulnerability that allowed a normal user to take over the Owner account of an entire organization.

And I'll explain it so simply that even someone new to security can understand it.

The Setup: Understanding the Roles

The application had two main roles:

  • Owner → The highest privilege. Full control.
  • Full Access User (Non-owner) → High privilege, but not the Owner.

In the UI, everything looked secure.

When you go to the Admin Accounts page:

  • You cannot edit other users.
  • Even the Owner cannot edit others.
  • The only visible option is "Show Sessions".

So at first glance, it looks safe.

No "Edit User" button. No "Change Password" option. Nothing dangerous.

But here's the important lesson:

If the UI blocks it, that does NOT mean the backend blocks it.

The UI is just the front door. The backend is the real security guard.

Step 1: Clicking "Show Sessions"

As a Full Access user, I clicked:

"Show Sessions" for the Owner account.

I intercepted the request using Burp Suite.

And there it was.

A parameter called:

admin_id

This was the unique identifier of the Owner account.

That means:

I now had the internal ID of the Owner.

This ID is not supposed to be dangerous by itself.

But what if the backend trusts it too much?

None

Step 2: Editing My Own Profile

Next, I edited my own profile.

This action sent a request to:

POST /admin/usersManage.php

The request looked like this:

POST /admin/usersManage.php

Inside the body, I saw:

admin_id=MY_ID

Now think like a hacker.

The backend is saying:

"Who do you want to edit? Tell me their admin_id."

And I already know the Owner's admin_id.

So what happens if I replace:

admin_id=MY_ID

with:

admin_id=OWNER_ID

And then add:

admin_password_new=HACKER_PASSWORD

Let's try.

Step 3: Changing One Line

Here's the modified request:

POST /admin/usersManage.php HTTP/2
Host: target.com
Cookie: <full-access-user-session>
faction=edituser&
admin_id=OWNER_ADMIN_ID&
save=1&
admin_password_new=HACKER_PASSWORD&
admin_name=farestestd&
admin_email=33333%40belgianairways.com&
admin_phone=&
admin_signature=%3Cp%3Efares%3C%2Fp%3E

I sent it.

And the server said:✅ Success.

None

No error. No permission check. No "you are not allowed".

The Owner's password was changed.

Step 4: Logging in as the Owner

I logged out.

Then I logged in as: owner email with the new password I set. And I was inside.

Full Owner access.

Full organization control.

No phishing. No brute force. No malware.

Just changing one ID.

Insecure Direct Object Reference (IDOR)

The backend trusted a parameter sent by the user (admin_id) without checking:

  • Who is making the request?
  • Are they allowed to modify this target?
  • Is the role hierarchy respected?

The system assumed:

"If you know the ID, you must be allowed."

That assumption destroyed the entire security model.

Contact Me: https://www.linkedin.com/in/mohamed-fares-208008229/

https://x.com/_2os5