Cross-Tenant Authorization Bypass

Hello,

Today, I will walk through how I discovered a Cross-Tenant Authorization Bypass in OpenAI platform, which allowed an attacker to gain unauthorized control over groups belonging to another organization with no prior relationship

Imagine being an organization owner, only to find that an external attacker can manage your groups — adding members, removing users, or even deleting the group — without your knowledge.

After mapping the application and understanding its business logic and main features, I decided to focus more on the team management functionality.

I noticed that it mainly consists of four components: members, invitations, groups, and roles.

The application defines two main roles:

• Owner: has full access and control over the organization
• Reader: has limited, mostly read-only permissions

To test this properly, I created two organizations:

• Organization A (attacker)
• Organization B (victim)

Then, the victim organization invited the attacker as a Reader. So now, the attacker has:

• Owner access in his own organization
• Reader access in the victim organization

While testing, I decided to focus on the group feature, which allows creating groups and assigning roles such as Owner or Reader.

As expected, having a Reader role in the victim organization does not allow me to create or manage groups there.

At this point, I started thinking:

What if I could somehow reference or link a group from my organization to a group that belongs to another organization?

From attacker organization (where I have Owner privileges), I created a group and started testing the role assignment functionality.

While intercepting a request to the role assignment endpoint using Burp Suite, I identified a parameter called principal_id, which is used to specify the target group ID for role assignment.

So I asked myself

What happens if I replace this principal_id with a group ID from the victim organization?

I modified the request and sent it — and it worked.

The request was accepted successfully.

As a result, the victim's group was linked and controlled through my organization, even though I only had Reader access in that organization.

After that, I asked myself: can this work without having any relationship with the target organization at all? So I left the victim organization and tried again — and it still worked.

This is not just about modifying or reading data — it gives full control over the group, by just knowing the victim's group ID.

Scenario 1 - Attacker is a Reader in the victim org:

1. Create two organizations: Organization A (attacker) and Organization B (victim).
2. Invite the attacker to Organization B as a Reader.
3. From Organization B, create a group .
4. From Organization A, create a group and intercept the role assignment request using Burp Suite.
5. Replace the principal_id value with the group ID from Organization B.
6. Observe: the server returns 200 OK — the attacker now has full control over the victim's group.

Scenario 2 — Attacker has no relationship with the victim org:

1. Create a completely separate organization with no connection to the attacker.
2. Obtain the target group ID- which is not easily enumerable -and replace the principal_id with it.
3. Observe: the exploit still works with zero prior relationship.

Impact

The attacker has full control over the victim's group, which leads to:

• Add members
• Delete members
• Delete the group

Conclusion

Assumption → Probe → Proof of Concept