Post cover image

September 29, 2026

How I Made €200 Bypassing Cross-Portal Access Control

Hey everyone! In this writeup, I’m excited to share my experience finding a Broken Access Control / Cross-Portal Authorization Bypass…

By Utaa

2 min read

Hey everyone! In this writeup, I'm excited to share my experience finding a Broken Access Control / Cross-Portal Authorization Bypass vulnerability in a private bug bounty program.

What made this finding interesting was how a simple logic flaw across two related workflow features netted a total of €200 in bounties across two separate reports.

To respect the program's privacy guidelines, we will refer to the target domain as redacted.com.

1. Understanding the Architecture: Multi-Portal Setup

redacted.com operates as a multi-tenant B2B platform featuring isolated "Portals" for different organizations. Within this platform, organizational structures are managed through two main entities: Business Units (BU) and Group Business Units (Group BU).

Under their Role-Based Access Control (RBAC) model, access should strictly enforce the following rule:

  • An Admin assigned to Portal A should only manage Business Units within Portal A.
  • They must never be able to create, edit, or delete Business Units belonging to Portal B.

On the user interface (UI) level, this control seemed to be in place. Buttons to add or edit units for organizations outside the user's scope were disabled or hidden. But as bug hunters know: Client-side restrictions are not real security.

2. Bug #1: Never Trust Client-Side Controls (€100)

While testing the Group Business Unit creation feature, I noticed that the web UI prevented my account (Portal A Admin) from selecting or creating groups for other organizations.

I bypassed the UI restriction and analyzed the backend request using Burp Suite. The creation request was sent directly to:

/admin/organizations/group-business-units/new

This endpoint required a key parameter: targetAccountId (an identifier representing the organization's account).

The Recon Step:

To exploit this, I needed a valid targetAccountId belonging to a victim organization (Portal B). I tested the listing endpoint: POST /business-units/list

By sending a standard payload {"limit": 1000, "offset": 0}, the server responded with a complete list of Business Units across all portals, exposing their respective targetAccountId values.

The Exploitation:

I grabbed a targetAccountId belonging to Portal B (e.g., 0017Qxxxxxx) and crafted a direct POST request:

POST /admin/organizations/group-business-units/new HTTP/1.1
Host: api.redacted.com
Authorization: Bearer <admin_token_portal_A>
Content-Type: application/json

{
  "targetAccountId": "0017Qxxxxxx",
  "groupName": "got Hacked"
}

The backend failed to validate whether my authenticated session had management rights over targetAccountId. The server responded with HTTP 200 OK, and the new Group BU was successfully created inside the victim's portal.

I submitted the report, and €100 was awarded.

3. Bug #2: Escalating to Edit & Delete (€100)

After the first report was accepted, I asked myself: "If creation lacks ownership checks, what about modification and deletion?"

I investigated the sister endpoints handling individual Business Units:

  • /admin/organizations/business-units/new
  • /business-units/group/{id}

The Workflow:

  1. Authenticated as an Admin for Portal A.
  2. Extracted victim entity IDs from Portal B via /business-units/group/list.
  3. Sent direct UPDATE and DELETE requests targeting those entity IDs.

Deletion Logic Flaw:

When sending a DELETE /business-units/group/{victim_group_id} request, the server returned an error response:

{"code":"FAILED","description":"Can not delete group business unit"}

However, upon refreshing the target state, the entity was actually deleted! The backend executed the deletion query despite returning a failure status to the client — a classic example of flawed response handling.

Modification Logic Flaw:

I was also able to arbitrarily edit the titles and properties of Business Units belonging to other organizations.

Since this flaw affected distinct endpoints and directly impacted Business Unit assets (rather than just groups), I submitted it as a second report. Although initially flagged as a potential duplicate, I clarified the distinct scope and endpoint behavior with the triage team. The report was re-opened and accepted for an additional €100!

4. Key Takeaways

  1. Frontend Restrictions ≠ Backend Security: Disabling UI elements or modifying DOM state does not secure an API. Always test direct HTTP requests.
  2. Enforce Server-Side Ownership Checks: Ensure every sensitive API endpoint verifies: "Does the authenticated user own or have explicit permission to manage the target object ID?"
  3. Communicate Clearly with Triagers: If your report is initially closed or miscategorized, politely provide step-by-step evidence explaining why the endpoint or scope is distinct.

Happy hunting!

None