Hello, Assalamualaikum. After a long time I thought need to write something on medium as got enough response on previous writeup. So lets deep dive into it hope you would like it.

Introduction

In this research, we discovered a critical Broken Access Control vulnerability (IDOR) in an embedded-content API endpoint that allows attackers to access private organization-scoped resources belonging to other tenants, simply by modifying a resource identifier in the request.

No ownership or authorization validation is performed on the server side. In some cases, the endpoint even responds without any Authorization header, indicating a complete absence of authentication enforcement.

Step-by-Step Exploitation Flow

Step 1: Lets understand the flow

In bookshelf one can add private external link to the private group content

None

And in the logger we can see a UUID is generated for the external link

None

In another request i observed that through the bellow request with embedded content unique UUID we can view the external link added

None

So the curiosity in my mind says is it possible if we can view external link of another private group with the UUID ?

Then from another account another group i tried to add a content to the private group

None

Got its UUID

None

Then came to the first account and in the https://api.domain.com/User-content/embedded-content?ids=32116406–1054–4633-bf1e-941364190143 http request

I swapped embedded-content id of both accounts

None
None

Yup its showing the content even though the groups are private.

Also found that without JWT token its also showing the content

None

But the thing is its a bug Ok. But how one can get those UUIDs ?

In the impact i tried to prove that its happening on a GET request so it can be found on the web archeive. And tried to find more similar endpoint in the archeive but could not found one.

some of you may ask is this a valid bug

~ If you are hacking on Hackerone then its a valid but cuz a common misconception in vulnerability triage is that long or unpredictable UUIDs automatically prevent IDOR exploitation. This assumption is incorrect — and contradicts both real-world attack models and HackerOne's own platform standards.

This issue is a textbook example of why authorization matters more than identifier entropy.

The Core Misunderstanding

"The resource ID is a 32–36 character UUID, so it cannot be guessed."

Correct — but guessing is not required.

IDOR does not require brute-forcing identifiers. IDOR occurs when an attacker can access a resource they are not authorized to access, regardless of how the identifier is obtained.

HackerOne Standards Explicitly Support This

HackerOne's Detailed Platform Standards clearly state

  • IDORs with unpredictable identifiers are still valid
  • Attack Complexity should only be "High" if the ID cannot realistically be obtained
  • If the report demonstrates a realistic method to obtain the ID, the vulnerability stands
  • Severity should be based on impact, especially for cross-tenant data access

This case meets all criteria:

  • Realistic ID exposure
  • Cross-organization access
  • Confidentiality impact
  • Missing authorization

Source: 📄 HackerOne Detailed Platform Standards https://docs.hackerone.com/en/articles/8369826-detailed-platform-standards

Also I previously reported an IDOR/Improper Access Control to this same program (#3300276) that also involved a long, unpredictable 32–36-character UUID (group_id). That report was accepted and rewarded because the issue did not rely on guessing the UUID — it was exposed through normal application flows. The current vulnerability follows the exact same pattern.

Thanks to all for reading.