Post cover image
Me rapidly testing requests in Burp Suite.

September 26, 2026

BAC to Full Takeover: How I Escalated Privileges and Kicked Out the Real Owner💥

👨‍💻 Meet the Author

By MD Mainul Islam Siam

3 min read

👨‍💻 Meet the Author

Hey everyone! 👋 I'm MD Mainul Islam Siam (known as x0xhomelander across the bug bounty scene). I'm an Ethical Hacker and Security Researcher who loves hunting down deep logic flaws and authorization bypasses in modern web applications. 🛠️

I regularly report critical findings on HackerOne and YesWeHack, specializing in:

  • 🎯 Broken Access Control (BAC) & IDORs
  • 🔑 Authentication & Privilege Escalation Flaws
  • 🧩 Complex Business Logic Bypasses

🌐 Connect & Follow My Journey:

🛑 The Core Concept: What is Broken Access Control?

Before diving into the hack, let's talk about a golden rule in web security:

Access control ensures that users cannot act outside of their intended permissions.

When developers hide a button on a webpage, they often assume users won't click it. But hiding an option in the browser is not security. If the server behind the scenes blindly trusts the data coming from the user's browser without double-checking their permissions, Broken Access Control (BAC) occurs.

This is the story of how relying on client-side UI restrictions destroyed an entire organization's authorization boundary.

🔎 Step 1: The Initial Reality Check

During a recent target assessment of a multi-tenant SaaS application, I was analyzing its organization management system. The platform had three distinct roles:

  • 👑 Owner: Holds ultimate power (billing, member management, organization deletion).
  • 🛡️ Admin: Manages daily operations and invites new team members (with restricted permissions).
  • 👤 Member: Standard user with basic read/write access.

When testing as an Admin, I navigated to the Team Invitations panel. A dropdown menu offered roles to assign to the invitee: Admin or Member.

The Owner option was completely missing from the UI menu.

[ What the UI Showed to an Admin ]
Role Options:
 ⭕ Member
 ⭕ Admin
 ❌ Owner (Option completely hidden)

At first glance, the application looked secure. But as security researchers, we always ask one crucial question:

Is the backend API actually checking if I'm allowed to assign the Owner role, or is it just hiding the option in my browser? 🤔

🕵️ Step 2: Intercepting the Traffic

To test the server's validation logic, I set up two accounts:

  • Account_A → The primary, legitimate Organization Owner 👑
  • Account_B → An account invited by Account_A as an Admin 🛡️

I logged into Account_B (Admin), typed in a secondary test email address, selected Admin from the role dropdown, and fired up Burp Suite 🎯 to capture the HTTP request before it reached the server.

None None

Here was the clean JSON payload intercepted on its way to the backend API:

HTTP

POST /api/v1/organization/invitations HTTP/1.1
Host: target-app.com
Authorization: Bearer <ADMIN_JWT_TOKEN>
Content-Type: application/json
{
  "email": "attacker-test@example.com",
  "role": "admin"
}

😮 Step 3: Testing the Authorization Boundary

Now came the critical test. I tampered with the JSON body, replacing "admin" with "owner":

JSON

{
  "email": "attacker-test@example.com",
  "role": "owner"
}

I forwarded the modified request, expecting the server to throw a 403 Forbidden error saying "Admins are not allowed to invite Owners."

Instead, the server responded with a crisp 201 Created! 🚨

None

HTTP

HTTP/1.1 201 Created
Content-Type: application/json
{
  "status": "success",
  "message": "Invitation sent successfully",
  "data": {
    "role": "owner"
  }
}

The backend trusted the parameter passed in the API body without verifying if Account_B (an Admin) possessed the authority to grant Owner status!

💥 Step 4: The Escalation & Full Takeover

The vulnerability was already proven, but demonstrating full impact is what makes a bug report critical. Here is how the complete takeover path was executed:

  • Accepting the Invite: I opened the invitation email sent to attacker-test@example.com and completed registration. 📩
  • Checking Privileges: The newly registered account immediately held full Owner status in the organization! 👑
  • The Final Lockout: Logged in as the rogue Owner, I went to Organization Settings ➔ Members, clicked on Account_A (the real original Owner), and clicked Remove. ❌
None 
🛡️ Admin User (Account B)
       │
       ▼ (Intercept & Tamper: "role": "owner")
📩 Unauthorized Owner Invitation Sent
       │
       ▼ (Accept Invitation Link)
👑 Escalated to Full Owner Privileges
       │
       ▼ (Revoke Access)
❌ Original Owner Removed from Tenant
       │
       ▼
💥 Complete Organization Takeover Achieved!

In less than two minutes, a lower-privileged Admin seized the entire tenant and locked out the real owner permanently.

🚨 Impact & Severity

  • Severity: Critical (CVSS 9.1) 🚨
  • Impact Type: Broken Access Control / Privilege Escalation
  • Confidentiality: Total exposure of sensitive company records, customer details, and API tokens.
  • Integrity: Complete administrative authority to alter or wipe out organizational resources.
  • Availability: Irreversible lockout of legitimate administrators.

📩 Disclosure & Conclusion

I submitted a detailed report containing clear reproduction steps to the security team:

  • Status: Verified & Triaged as Critical 🚨
  • Resolution: Patched on the backend & Rewarded 🏆

Thanks for reading! If you learned something new about access control today, give this post a few claps 👏 and follow me for more real-world security research and writeups! 🚀

Keep Hunting, Keep Securing! 🛡️