Uncovering a Privilege Escalation Vulnerability in Trello: Unauthorized Deletion of Boards

By Deev/techycodec08, December 16, 2024

Introduction

A few months ago, I had the opportunity to dive deep into the security of Trello, a widely-used project management tool by Atlassian.

What started as a routine exploration turned into the discovery of a Privilege Escalation that allowed a normal Workspace Member to bypass board deletion restrictions set by Workspace Admins.

After reporting it through Bugcrowd’s bug bounty program on December 16, 2024, Trello Accepted the bug as P3 (Medium), and paid a bounty of $1200. Trello recently fixed the issue and approved my request for public disclosure. Today, I’m excited to share the full story of this bug, how I found it, and its implications.

You can find the official disclosed report here: Bugcrowd Disclosure Link

The Bug in a Nutshell

The vulnerability I uncovered falls under the category of Broken Access Control (BAC) > Privilege Escalation, classified as a P3 priority issue with a CVSS score of 6.5 (Medium).

In short, it allowed a normal Workspace Member in a Premium Trello Workspace to delete any board—public, private, or workspace-visible—despite explicit restrictions set by Workspace Admins prohibiting such actions. This bypass effectively undermined the access controls designed to protect boards from unauthorized deletion.

Summary by Trello: “Workspace Board Authorization Bypass Vulnerability”
My Summarization: “A Normal Workspace Member can bypass the restriction of Board Deletion Permission set by Workspace Admins, to delete any board in the workspace”

Setting the Scene: Trello’s Workspace Permissions

In a Premium Trello Workspace, Admins have granular control over who can delete boards. This feature is critical for organizations relying on Trello to manage projects, ensuring that sensitive boards aren’t accidentally—or maliciously—wiped out by regular members.

The Workspace Settings offer three options for board deletion permissions across all visibility types:

Anyone can Delete Boards – Full access for all members.
Workspace Admins can Delete Boards – Restricted to Admins only.
No one can Delete Boards – Locked down completely.

When Admins select the second option—“Workspace Admins can Delete Boards”—normal Workspace Members are barred from deleting boards. They’re also prevented from closing a board and reopening it in another workspace they own, as this would effectively remove (delete) it from the original workspace.

On the surface, this seemed like a robust access control mechanism.

The Discovery Process

Step 1: Exploring the Restrictions

To test this, I set up a controlled environment. As a Workspace Admin, I added a test user as a normal Workspace Member to a Premium Workspace. I then navigated to the Workspace Settings and restricted board deletion to Admins only.

From the Admin perspective, everything looked secure.

Switching to the Workspace Member account, I created a test board within the workspace. As expected, the UI blocked me from deleting it—regardless of visibility (public, private, or workspace-visible). The “Delete” option was grayed out, and I was not able to delete the Board from the UI.

So far, so good. Trello’s restrictions appeared to be working as intended.

Step 2: Digging Deeper with Burp Suite

Not satisfied with the surface-level behavior, I fired up BurpSuite to inspect the underlying HTTP requests. I tried sending a manual DELETE request to remove the board, but Trello’s API responded with an Unauthorized error.

This reinforced that direct deletion was indeed blocked for Workspace Members.

Also, attempting to close and reopen the board in a personal workspace I owned resulted in an error: “You don’t have permission to move this board to another workspace.”

However, I noticed something interesting: As we knew that Trello allows Workspace Members to move boards they own to other workspaces they control, as long as permissions allow it.

But what if I could manipulate this functionality to bypass the deletion restriction? After all, moving a board out of the original workspace effectively deletes it from that context—a violation of the Admin’s intent.

Step 3: Crafting the Bypass

After some experimentation, I discovered that a carefully crafted PUT request could move a board to another workspace owned by the Workspace Member, circumventing all restrictions.

Here’s the request that did the trick:

PUT /1/boards/67602d9ba379b5827eb9c49c HTTP/2
Host: trello.com
Cookie: 
User-Agent: Mozilla/5.0
Content-Type: application/json
X-Trello-Task: delete-board
{
   "idOrganization": "67601adaca94c108be43106b",
   "dsc": ""
}

Key Components:

Board ID (67602d9ba379b5827eb9c49c): Extracted from the board’s URL, visible to all Workspace Members.
idOrganization (67601adaca94c108be43106b): The ID of a different workspace owned by the Workspace Member.

When I sent this request, the board was successfully moved to my personal workspace, effectively deleting it from the original workspace where deletion was prohibited. From there, I could delete it permanently in my own workspace.

The restrictions—both in the UI and API—were completely bypassed.

The Impact: Why This Matters

This vulnerability is a textbook example of Vertical Privilege Escalation, where a lower-privileged user (a Workspace Member) gains capabilities reserved for higher-privileged users (Workspace Admins).

In a real-world scenario, this could have serious consequences:

Data Loss: A malicious or disgruntled Workspace Member could delete critical boards, disrupting workflows or erasing valuable project data.
Policy Violation: Organizations relying on Trello’s access controls to enforce governance would find their security posture undermined.
Trust Erosion: Users expect Admin-set permissions to hold firm, and this bypass breaks that trust.

The Severity: Explaining the CVSS Score

The CVSS score of 6.5 (Medium) reflects the potential impact:

Attack Vector: Network (AV:N) – Exploitable remotely.
Attack Complexity: Low (AC:L) – Requires minimal effort.
Privileges Required: Low (PR:L) – Only needs Workspace Member access.
Integrity Impact: High (I:H) – Deleting a board without permission affects integrity.

While confidentiality and availability weren’t directly impacted (C:N/A:N), the ability to delete boards at will is a significant breach of access control.

Reporting and Resolution

I submitted the vulnerability to Trello via Bugcrowd on December 16, 2024, at 15:03:25 UTC, under the target trello.com (Web App category). After a thorough review, Trello’s team acknowledged the issue, fixed it, and recently approved my disclosure request. I’m grateful to Atlassian for their responsiveness and commitment to security, as well as Bugcrowd for facilitating the process.

Lessons Learned

This experience reinforced a few key lessons for me as a security researcher:

Don’t Trust the UI: Frontend restrictions often hide backend vulnerabilities. Tools like Burp Suite are invaluable for peeling back the layers.
Think Creatively: Moving a board wasn’t explicitly “deleting” it, but it achieved the same outcome. Lateral thinking is critical in bug hunting.
Access Control is Fragile: Even well-designed systems can have subtle flaws in authorization logic.

For Trello users, this serves as a reminder to monitor workspace activity closely—especially in Premium Workspaces where permissions are customized. For developers, it’s a call to validate permissions at every step of a resource’s lifecycle, not just at obvious endpoints.

Final Thoughts

Finding and reporting this Privilege Escalation vulnerability was a rewarding journey. It’s a privilege to contribute to the security of tools like Trello that millions rely on daily.

I hope this write-up sheds light on the bug hunting process and inspires others to explore, test, and secure the digital world we share. Feel free to reach out with questions—I’d love to hear your thoughts! And if you’re curious about the nitty-gritty, check out the full disclosure on Bugcrowd here .

Happy hunting!!!!!