Post cover image

October 13, 2026

How I Found a Bug Bounty Vulnerability That Let Me Remove Other Users’ Access

How I found my first resolved vulnerability after duplicates and informative reports.

By Ashour0x

3 min read

How I found my first resolved vulnerability after duplicates and informative reports.

Hey, I'm Ashour — a Computer Science student, cybersecurity mentor, and aspiring penetration tester.

My bug bounty journey hasn't been a straight path. Some reports ended up as duplicates, others were marked informative, and every report taught me something new.

Let's start

None

🎬 First, Understanding the Application

The application was built around Notebooks and Pages.

Think of a Notebook as the main workspace for an entire engineering project. Inside it, users create Pages containing the project's content and visualizations.

To access a project, a user first needs an invitation to the Notebook. To access a specific Page content, they also need to be invited to that Page separately.

This distinction became important during my testing.

Users could be assigned different roles, from Viewer to Admin, with different permission levels.

100 — Viewer

200 — Contributor

300 — Author

400 — Editor

500 — Admin

I wanted to understand how the application enforced those permissions on the server, not just what the interface allowed.

🔍 The First Attempt: Notebook

While exploring how collaborators were added, I noticed that inviting users triggered requests to a user-management endpoint.

The first one I investigated was:

POST /api/notebook/[NOTEBOOK_ID]/save-users

I captured the request and tried modifying it using my own authenticated session to increase my permissions.

The server rejected the attempt:

{
  "message": "Cannot modify the permissions of a user with a higher role than your own",
  "data": null,
  "error": null
}

My attempt failed. But it also gave me a useful clue: the server was checking role hierarchy for this operation .

Did the corresponding Page endpoint enforce the same restrictions?

🧩 The Turning Point: Page

I moved into the project itself and examined how users were invited to individual Pages.

When a user clicked Done in the Page-sharing interface, the application sent a request to:

POST /api/page/[PAGE_ID]/save-users

I captured the request and examined its JSON body. It contained the Page's user list and permission values.

I first used my lower-privileged attacker's authentication token to test whether I could escalate my own permissions or increase another user's privileges.

Both attempts failed.

Instead of repeating the same tests, I examined how the endpoint handled changes to the submitted user list. I decided to test whether I could remove the administrator or reduce their permissions.

The Original JSON

The original response showed the administrator with permission level 500, alongside other collaborators with lower permission levels:

{
  "_id": "[PAGE_ID]",
  "name": "Default",
  "isPublic": false,
  "createdBy": {
    "permissions": 500,
    "_id": "[ADMIN_MEMBERSHIP_ID]"
  },
  "users": [
    {
      "permissions": 500,
      "_id": "[ADMIN_MEMBERSHIP_ID]"
    },
    {
      "permissions": 200,
      "_id": "[CONTRIBUTOR_MEMBERSHIP_ID]"
    },
    {
      "permissions": 300,
      "_id": "[AUTHOR_MEMBERSHIP_ID]"
    },
    {
      "permissions": 400,
      "_id": "[EDITOR_MEMBERSHIP_ID]"
    }
  ],
  "parent": null,
  "notebook": "[NOTEBOOK_ID]",
  "userPermissions": {
    "permissions": 200
  }
}

The Modified JSON

Using the attacker's valid authentication token, I removed the administrator's entry from the submitted users list:

{
  "users": [
    {
      "permissions": 200,
      "_id": "[CONTRIBUTOR_MEMBERSHIP_ID]"
    },
    {
      "permissions": 300,
      "_id": "[AUTHOR_MEMBERSHIP_ID]"
    },
    {
      "permissions": 400,
      "_id": "[EDITOR_MEMBERSHIP_ID]"
    }
  ]
}

The server accepted the change, and the administrator lost access to the Page.

I went further and tested whether I could reduce other users' permission levels instead of removing them entirely. That worked too. I could also remove other users from the Page.

The impact was more serious than I initially expected. A lower-privileged collaborator could interfere with other users' access to the project, potentially locking them out of a Page they were supposed to access.

If the affected users lost access without understanding what had happened, identifying the cause could also become difficult. This could disrupt collaboration and leave users unable to access their project content through the affected Page.

The issue was no longer about privilege escalation alone. It was a Broken Access Control vulnerability that allowed unauthorized changes to other users' permissions and memberships.

🛠️ From Vulnerability to Fix

After reporting the issue and working with the security team, the vulnerability was fixed.

During retesting, the server rejected attempts to modify the permissions of a higher-role user and returned the following response:

{
  "message": "Cannot modify the permissions of a user with a higher role than your own",
  "data": null,
  "error": null
}

This demonstrated that the server was enforcing the role-hierarchy restriction that had been missing from the vulnerable operation.

The report was eventually marked Resolved.

None