# A High-Severity P2 Business Logic Bug That Locks an Owner Out of Their Own Organization Hello hunters 👋\ I’m **Yassin (khoof)**, and today I want to share a **business logic flaw** that is surprisingly easy to miss — yet very impactful.\ This is the kind of bug you’ll find hiding quietly in many applications that rely on **Role-Based Access Control (RBAC)** and multi-organization collaboration. Let’s dive in 🧠 *** ### 🎯 About the Target The target application (hosted for example at `manage.target.com`) is built around: * Organization-based access * Role-Based Access Control (RBAC) * Products, each with granular permission sets * Cross-organization collaboration via invitations Users can: * Belong to multiple organizations * Switch between orgs using the UI * Be invited to collaborate across org boundaries All sounds normal… until it isn’t. *** ### 🔍 What Did I Do? As usual, I started my hunt by exploring **core functionality**: * How invitations work * How org switching works * How access is enforced * What happens when permissions change mid-session For testing, I invited another user — let’s call them **the victim**. * The victim already owns **Org B** * I (the attacker) control **Org A** * The victim uses the **same email** in both orgs The victim accepts the invitation and joins Org A. At this point, everything behaves exactly as expected: * The victim can switch between Org A and Org B * The UI provides a clear org-switching option
*** ### ❗ Where Is the Problem? This is where curiosity kicked in. > “What happens if I remove *all* access from a user while they are currently active in my org?” First, a quick clarification. #### 🧩 What Is “Product Access”? Product access is a custom permission layer that allows org owners to: * Grant or revoke access to specific products * Fine-tune what users can see or do inside an org As the owner of Org A, I can fully control this. So… I did exactly that. *** ### 💥 The Breaking Point While the victim was **actively using Org A**, I: * Opened **User Management** * Selected the victim * Removed **all product access** * Saved changes What happened next? *** #### Expected Behavior ✅ * Victim loses access to Org A * Victim switches back to Org B #### Actual Behavior ❌ * Org UI fails to load * Error screen appears * No navigation * No org switch * No escape
The org-switching feature simply **disappears**. *** ### 🔒 The Lockout Here’s the real issue: * The victim cannot access Org A (expected) * But **also cannot return to Org B** * Logging out and back in doesn’t help * The session always defaults back to Org A * The UI provides **zero recovery options** At this point, the user is **fully locked out of the platform**. 🎯 This is a **clean, persistent lockout**. *** ### 🤔 “Is This Really Exploitable?” At first, I hesitated. I asked myself: * How would an attacker *force* a victim to accept an invite? * Would triage say this requires too much social engineering? * Is the attack complexity too high?
Then it clicked. *** ### 🏢 The Real-World Angle (This Is the Key) I take a time to thinking how can we force the victim to join our ORG, or how can we do it without made the victim think that is attack on him.\ After much research and consideration of how to utilize it effectively, I realized that since the application allows users to access and switch between multiple orgs, it implies collaborative work, such as cross-organ product development, partnerships, or client-vendor engagement. In other words, users can collaborate and create interconnected orgs. SO????? yes we can made it under collaborative business. So i reported it with a real world scenario, and here is it:
*** #### Real-World Scenario This scenario assumes that both the attacker and the victim are users from separate organizations who may have **business or collaborative work** with each other, such as cross-org product development, partnerships, or client-vendor engagement. **1. Context: Collaboration Setup Between Two Organizations** * The attacker is an admin in **Org A** * The victim is a user/admin in **Org B** * Both users are expected to work together on a shared project or service that justifies collaboration **2. Step 1: Invite the Victim to Collaborate** * As part of the collaboration, the attacker invites the victim's email (already in use in Org B) to join **Org A** * The attacker assigns the victim access to at least one product in Org A — making the invite look legitimate and functional **3. Step 2: Victim Accepts the Invite** * The victim, assuming it's part of their work engagement, accepts the invitation * This causes the victim's session to switch to Org A, where they begin working **4. Step 3: Attacker Removes All Access** * After the collaboration appears to begin, the attacker goes to the **user management panel** in Org A * They locate the victim's profile and **remove all product and feature access** for that user * No admin rights, no product roles — effectively removing all functionality. 5. **Step 4: Victim is Trapped** * Upon refreshing or navigating the application, the victim sees an **error screen** such as “You have no access.” * Critically, the UI does not provide any method to **switch back to Org B**, even though the user is still a member of that org. 6. **Step 5: Lockout Persists Across Sessions** * Logging out and logging back in does not help — the application still defaults the session to Org A (with no access). * The victim is now **permanently trapped** in an inaccessible state and **cannot reach their own organization**, Org B, through the UI. *** #### **Intentional Misuse in a Real-World Scenario**: This attack flow reflects how a **malicious collaborator** can exploit trust and system design to **silently trap or sabotage a partner** or client during legitimate cross-org collaboration. No technical exploit is needed — just intentional misuse of role management logic.
### ✍️ Reported By **Yassin (khoof)** GET /**BountyOrDie** Team Member 💰 🔗 HackerOne Profile: 👉
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://get-bountyordie.gitbook.io/get-bountyordie-docs/our-write-ups/web-pentest-write-ups/a-high-severity-p2-business-logic-bug-that-locks-an-owner-out-of-their-own-organization.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.