Post cover image

May 12, 2026

From Viewer to Admin — Breaking Organization Isolation in a VDP Platform

I’m Montaser Mohsen, a security researcher focused on web application security and broken access control vulnerabilities.

montaser mohsen

4 min read

Recently, I discovered a critical authorization vulnerability in a Vulnerability Disclosure Platform (VDP) that allowed a low-privileged Viewer account to gain administrative control over arbitrary organizations.

The issue was caused by missing server-side authorization checks in organization management APIs.

What made this vulnerability particularly dangerous was that the platform trusted user-supplied organization identifiers without properly validating whether the authenticated user actually had permission to interact with the targeted organization.

As a result, a Viewer-level user could perform privileged actions against organizations they should never have been able to access.

This article explains:

  • How the platform worked
  • How the vulnerability occurred
  • How a Viewer account effectively became an Admin
  • The real security impact
  • Key lessons developers should learn from this issue

About the Platform

The application is a multi-organization VDP platform where users can create organizations and invite collaborators with different permission levels such as:

  • Viewer
  • Modeler
  • Admin

Each organization was intended to remain isolated from others, and users were only supposed to manage organizations where they had appropriate permissions.

That isolation failed because authorization checks were not properly enforced server-side.

The Core Issue

The backend trusted the organizationId supplied by the client in API requests.

The application failed to verify:

  • Whether the authenticated user actually belonged to the targeted organization
  • Whether the user had permission to perform sensitive actions
  • Whether the requested resource should be accessible to that user

This created a complete authorization failure.

Instead of treating organizationId as a simple resource identifier, the application effectively treated it as a trusted authorization reference.

As a result, a low-privileged user could replace the organizationId in requests and interact with arbitrary organizations.

This issue combined aspects of:

  • Broken Access Control
  • Broken Object Level Authorization (BOLA)
  • Organization isolation failure

The vulnerability ultimately resulted in:

  • Cross-organization access
  • Privilege escalation
  • Unauthorized user management
  • Full compromise of organization integrity

Attack Scenario

The attacker only needed:

  • A normal authenticated account
  • Viewer access inside any organization

The attacker also controlled another organization used for testing legitimate requests.

The exploitation flow was straightforward:

  1. Capture legitimate requests from the attacker-controlled organization
  2. Replace the organizationId
  3. Send the modified request
  4. Perform privileged actions against another organization

No administrative privileges were required.

No user interaction was required.

Root Cause

The backend performed authentication checks but failed to properly enforce authorization checks against the referenced organization resources.

The vulnerability was caused by multiple security design failures:

  • Missing server-side authorization validation
  • Broken organization isolation
  • Trusting user-controlled identifiers
  • Missing object-level access control
  • Weak RBAC enforcement
  • Over-reliance on client-side restrictions

The platform assumed authenticated users would only submit organization IDs they legitimately controlled.

That assumption created a major trust boundary failure between authentication and authorization.

Step 1 — Enumerating Organizations

The platform exposed organization identifiers through a normal API endpoint.

GET /api/organizations HTTP/2
Host: target.com
Authorization: Bearer <viewer_token>

The response exposed valid organization IDs that could later be targeted.

This allowed attackers to identify accessible targets for further exploitation.

Step 2 — Adding an Admin User to Another Organization

The attacker intercepted a legitimate collaborator invitation request from their own organization.

They then replaced the organizationId with the target organization ID.

POST /api/organizations/<targetOrgId>/collaborators HTTP/2
Host: target.com
Authorization: Bearer <viewer_token>
Content-Type: application/json
{
  "user": {
    "emailAddress": "attacker@example.com",
    "role": "ADMIN"
  }
}

The server accepted the request without validating whether the attacker had permission to manage the targeted organization.

A Viewer-level user successfully added a new Admin account to another organization.

This demonstrated a complete breakdown of authorization enforcement.

Step 3 — Modifying User Roles

The same issue also affected role management APIs.

The attacker could modify roles of users inside organizations they should never have been able to manage.

PUT /api/organizations/<targetOrgId>/collaborators/<userId> HTTP/2
Host: target.com
Authorization: Bearer <viewer_token>
Content-Type: application/json
{
  "role": "READ"
}

This allowed attackers to:

  • Downgrade administrators
  • Promote users
  • Manipulate organization permissions
  • Maintain persistent unauthorized access

The Owner role had partial protection and could not be removed.

However, all other roles remained vulnerable.

Step 4 — Removing Users

The attacker could also remove users from arbitrary organizations.

DELETE /api/organizations/<targetOrgId>/collaborators/<userId> HTTP/2
Host: target.com
Authorization: Bearer <viewer_token>

This enabled operational disruption against targeted organizations.

Attackers could:

  • Remove collaborators
  • Disrupt internal operations
  • Lock out legitimate users
  • Create organizational chaos

Why This Vulnerability Was Dangerous

This was not a simple IDOR.

This vulnerability represented a complete breakdown of authorization boundaries.

The issue affected all three major security pillars:

  • Confidentiality
  • Integrity
  • Availability

A low-privileged Viewer account effectively became a cross-organization administrator.

Real Impact

Cross-Organization Data Exposure

Attackers could access:

  • User email addresses
  • Names
  • Organization structures
  • Internal collaborator information

Privilege Escalation

A Viewer user could:

  • Add Admin accounts
  • Modify permissions
  • Maintain persistent unauthorized access

Organization Takeover

Attackers could:

  • Control non-owner users
  • Disrupt operations
  • Create hidden backdoor administrators

Platform Security Failure

The platform's security model failed entirely:

  • RBAC protections were bypassed
  • Organization isolation collapsed
  • Authorization enforcement was missing

Interesting Observation

While testing the vulnerability, I discovered the platform prevented deletion of the Owner account.

Attempting to remove the Owner returned:

{
  "message": "The collaborator can't be removed."
}

This indicated that some protection mechanisms existed for Owner accounts.

However, the vulnerability remained highly impactful because attackers could still fully manage all non-owner users across arbitrary organizations.

Vendor Response

The security team initially requested additional proof demonstrating:

  • How organization IDs were obtained
  • Whether role modification worked
  • Whether user deletion was possible

I provided:

  • Multiple proof-of-concept videos
  • Separate demonstrations for each impact
  • Clarification that the attacker only had Viewer privileges

After validation, the report severity was updated and the issue was escalated for remediation.

The vendor later fixed the vulnerability completely.

Re-testing confirmed the issue was no longer reproducible.

Key Security Lessons

Never Trust User-Controlled Identifiers

Any identifier supplied by the client must always be validated server-side.

Enforce Authorization on Every Request

Authentication alone is never sufficient.

Every sensitive action must verify:

  • User identity
  • Organization membership
  • Role permissions

RBAC Must Be Enforced Server-Side

Client-side restrictions provide no real security.

Attackers can always modify requests manually.

Organization Isolation Is Critical

Isolation boundaries between organizations must be treated as strict security boundaries.

Once isolation fails, the entire security model can collapse.

Final Thoughts

Broken access control remains one of the most dangerous vulnerability classes in modern web applications.

The most severe vulnerabilities are often not advanced exploits or complex attacks, but simple authorization mistakes hidden behind trusted assumptions.

In this case, a single missing authorization check allowed a Viewer account to operate as a cross-organization administrator and compromise the integrity of the entire platform.

All because the backend trusted an organizationId supplied by the client.

Thanks for reading 🙏 I'll keep sharing more from my bug bounty journey.

Feel free to connect or share your thoughts

Facebook: https://facebook.com/montasermohsen98 Twitter (X): https://x.com/Montaser_M98 LinkedIn: https://linkedin.com/in/montasermohsen98