Broken Access Control leads to Addition of Malicious Files / Inclusion of Sensitive Files.

Hello Guys,

My good name is Saurabh Tripathi and I am back with another interesting finding.

LinkedIn - https://www.linkedin.com/in/saurabh-tripathi-1948273b

Broken Access Control Leads to Addition of malicious file

: A Step-by-Step Journey

As a cybersecurity enthusiast and bug bounty hunter, I recently stumbled upon a fascinating vulnerability that highlights a critical flaw in access control enforcement. This writeup walks through the discovery of a Broken Access Control issue in a web application—details redacted to respect responsible disclosure—where I could manipulate files across separate accounts without proper authorization.

In this case, the application let me upload a file in one account and then link it to a completely different account by tweaking an API request. Even though the server threw an error, the action succeeded, proving the access controls were more like a flimsy curtain than a steel door.

The Setup: Two Accounts, One Goal

To test this, I worked with two separate accounts on the platform—let’s call them Account A and Account B:

Account A: Hosted at [REDACTED-A].example.com with a unique Company ID (let’s say COMPANY-A).

Account B: Hosted at [REDACTED-B].example.com with a different Company ID (COMPANY-B).

These accounts represent distinct entities—think of them as two different organizations using the same platform. My hypothesis was simple: if I could upload a file in Account B and then trick the system into linking it to Account A, I’d expose a serious flaw.

Step 1: I started by logging into Account B ([REDACTED-B].example.com). Using the platform’s file upload feature, I added a test file—named BrokenAccessTest.png—to a folder. Let’s say this folder had an ID of FOLDER-B. After the upload, the system assigned the file a unique identifier, say FILE-XYZ. So far, so normal—everything stayed within Account B’s sandbox.

Step 2: Snooping on the API

Next, I fired up my Burp . When you link a file to a folder, the application sends a POST request to an API endpoint. Here’s what I captured from Account B:

POST /api/v1/folders/FOLDER-B/COMPANY/COMPANY-B/attachments/link
Host: [REDACTED-B].example.com
[Request Body includes FILE-XYZ]. The server processed it, and the file appeared in Account B’s folder as expected. Nothing suspicious yet—just standard functionality.

Step 3: The Sneaky Switch here’s where things got interesting. I wondered: what if I changed the folder ID and company ID to point to Account A instead? Using my proxy tool, I modified the request:

POST /api/v1/folders/FOLDER-A/COMPANY/COMPANY-A/attachments/link
Host: [REDACTED-B].example.com
[Request Body still includes FILE-XYZ]

FOLDER-A was a folder ID from Account A ([REDACTED-A].example.com).COMPANY-A was Account A’s company ID.FILE-XYZ remained the same—the file I uploaded in Account B.

I hit “Send” and braced myself. The server responded with a 500 Internal Server Error. At first, I thought I’d hit a dead end—500 errors usually mean something broke on the backend. But in bug hunting, errors can be deceiving, so I decided to double-check.

Step 4: The “Oops, It Worked” Moment I logged into Account A ([REDACTED-A].example.com) and navigated to the folder with ID FOLDER-A. To my surprise, there it was: BrokenAccessTest.png, sitting in Account A’s folder. Despite the 500 error, the file had successfully linked across accounts, proof that the access controls were broken.

How Did This Happen?Let’s break down the flaw:No Authorization Check: The API didn’t verify whether I had permission to link files to FOLDER-A in COMPANY-A. It blindly trusted the modified request.

Server-Side Mishandling: The 500 error suggests the backend hit a snag (maybe a logging issue or unhandled exception), but it still completed the linking action before failing.

Cross-Account Access: Since COMPANY-A and COMPANY-B are distinct entities, this shouldn’t have been possible without explicit cross-account permissions—which I didn’t have.In technical terms, this is a classic case of Insecure Direct Object Reference (IDOR) combined with insufficient access control enforcement.

The API relied on user-supplied IDs (FOLDER-A and COMPANY-A) without validating my authority over them.

The Impact: Imagine an attacker exploiting this:Data Exposure: They could link sensitive files (contracts, PII, etc.) from one organisation to another.

[All the IDs were sequential increasing the impact]

Data Tampering: They might upload malicious files and link them across accounts, disrupting operations or spreading malware.

Privilege Escalation: If one account has higher privileges, linking files could grant unintended access to restricted resources.Since these accounts belonged to different “companies” on the platform, this could even bridge organizational boundaries, exposing one entity’s data to another.

Lessons for Developers- This bug offers a few takeaways for building secure applications.

Validate Ownership: Always check if the user has permission to manipulate the resources referenced in API requests (e.g., folder IDs, company IDs).Fail Securely: A 500 error shouldn’t mean “half-success.” If something goes wrong, roll back the action—don’t let it complete.

Log and Monitor: Proper logging could’ve flagged this cross-account attempt, alerting the team to investigate.

Don’t Trust Errors: A 500 response doesn’t always mean failure—verify the outcome manually.

The Issue was addressed and fixed the very same day.

Swags ON THE WAY.

LinkedIn — https://www.linkedin.com/in/saurabh-tripathi-1948273b

Thanks For Reading.