How I Escalated Privileges in a File-Sharing Platform by Changing One Word

TL;DR

While testing a file-sharing platform API, I discovered that any authenticated shared user can approve file access requests on behalf of the file owner — by simply changing "request" to "approve" in a single API parameter.

No complex exploit. Just logic.

Target Overview

The target is a SaaS file-sharing and data protection platform — let's call it example.com. One of its core features is controlled file access — a file owner shares a file, and only the owner can approve or revoke access for other users.

That's the promise. Let's see if the API holds it.

Step 1 — Understanding the Access Flow

I always start with the product logic, not the tools.

The sharing flow works like this:

Owner (A) shares a file with User (B)
A third party © who has no access opens the share link
The "Request Access" button appears for User C
User C clicks it → a request is sent to the owner
The owner sees the request in their dashboard and approves or denies it

The key assumption the product makes is:

"Only the file owner can approve access requests."

Let's test that assumption.

Step 2 — Trigger the Request Access Feature

I logged in as User C — an account with no access to the file — and opened the share link.

Since User C has no access, a new button appeared on the page: "Request Access".

I clicked it and intercepted the outgoing request:

PATCH /acm/api/policies
Authorization: Bearer TOKEN_C
Content-Type: application/json

{
"uuids": ["FILE_ID"],
"authorizedUsers": ["userC@email.com"],
"doRequestAccess": "request"
}

PATCH /acm/api/policies
Authorization: Bearer TOKEN_C
Content-Type: application/json

{
"uuids": ["FILE_ID"],
"authorizedUsers": ["userC@email.com"],
"doRequestAccess": "request"
}

One field immediately caught my eye:

"doRequestAccess": "request"

"doRequestAccess": "request"

This is a client-controlled parameter that describes the intent of the action. The value "request" means "I'm asking for access." The natural question is: what happens if I send "approve" instead?

Step 3 — The Key Question

If the server only checks whether the user has access to the file — not what role they have — then any shared user could flip this to "approve" and act as the owner.

To test this properly I needed:

User B — a legitimate shared user (has access, but is NOT the owner)
User C — a user with no access (the target to be approved)

Step 4 — Crafting the Exploit

I switched to User B (the attacker), captured their valid authorization token, and sent the following modified request:

PATCH /acm/api/policies
Authorization: Bearer TOKEN_B
Content-Type: application/json

{
"uuids": ["FILE_ID"],
"authorizedUsers": ["userC@email.com"],
"doRequestAccess": "approve"
}

PATCH /acm/api/policies
Authorization: Bearer TOKEN_B
Content-Type: application/json

{
"uuids": ["FILE_ID"],
"authorizedUsers": ["userC@email.com"],
"doRequestAccess": "approve"
}

The only difference from the legitimate request: the token belongs to a shared viewer, and doRequestAccess is set to "approve" instead of "request".

Step 5 — Result

200 OK

200 OK

No error. No warning. No verification.

✅ User C received an email: "Your access request has been approved"

✅ Owner's dashboard showed User C was added

❌ The file owner was never asked

❌ The file owner received no notification

A viewer just acted as the owner — completely silently.

Impact

Complete Bypass of Ownership: The "Owner-only" privilege of approving access is completely broken.
Privilege Escalation: A low-privileged viewer acts as a High-privileged owner.

Contact With Me

LinkedIn: https://www.linkedin.com/in/kerolos-iskander-4a277033a

Contents