Trello Butler — Board Observer Can Share Automation Rules With the Entire Workspace

TL;DR

Trello boards have a role called Observer — a read-only role with the least privileges of any board member. Observers can't edit cards, can't create automations, and critically, they don't have the option to share automation rule libraries with other workspace members. That sharing toggle simply doesn't exist in their UI.

But the API endpoint responsible for sharing automation libraries — POST /api/powerup-library-share on Butler's backend — doesn't check the requester's board role. An Observer can send a direct API request to share their personal automation rule libraries with every workspace member, including the board owner. If the board owner then imports that shared library, the Observer's automation rules get added to the board — giving the Observer effective write access to a board they're supposed to only be watching.

The irony: Observers can't even see the "share" button. They can't create automations through the board UI. They have the absolute minimum level of access. And yet, through a single API call, they can push automation rules to the entire workspace — rules that, once imported by a privileged user, execute with full board modification capabilities.

Background — What is a Board Observer?

Trello boards support several membership roles, each with different levels of access:

Role	Can edit cards?	Can create automation?	Can share automation?
Board Admin	Yes	Yes	Yes
Normal Member	Yes	Yes	Yes
Observer	No	No	No

When do you use the Observer role? Observers are typically used for stakeholders who need to see what's happening on a board without being able to change anything — think of a client monitoring a project board, an auditor reviewing workflows, or an executive who wants visibility into a team's progress. The entire point of the Observer role is: look, but don't touch.

Observers are explicitly locked out of the automation system. They can't create rules, can't edit rules, can't delete rules, and they don't have the sharing toggle that other members see. From the UI, it's as if the automation system doesn't exist for them.

What Observers Can't Do

Let's walk through what the Observer actually sees when they try to interact with the board's automation features.

No edit access to the board. When an Observer opens a board, they can view cards and lists but can't modify anything. The board appears in a read-only state — no dragging cards, no editing descriptions, no adding comments.

No automation access. When other members (normal members and admins) open the Automation section, they see options to create rules, buttons, and scheduled commands. The Observer sees none of this — the automation controls are hidden.

No sharing toggle. Even if an Observer manages to create a personal automation library (through Butler's personal library feature, which operates outside the board context), the "share" toggle that normally appears in the library view is completely absent for Observers. Admins and normal members see a toggle to share their libraries with workspace members; Observers don't.

Three layers of restriction: Trello put up three barriers: (1) Observers can't create automations on the board, (2) Observers don't see the automation UI, (3) Observers don't have the share toggle. All three are client-side only. The server-side API behind the share toggle accepts requests from any role.

The Bug — Sharing What You Shouldn't Even Have

Despite all the UI-level restrictions described above, Butler's API endpoint for sharing automation libraries doesn't check the requester's board role. The endpoint is:

Vulnerable Endpoint

POST /api/powerup-library-share
Host: app.butlerfortrello.com

This endpoint accepts a Butler API token, a board ID, and a workspace ID. It shares the requester's automation library with all members of the specified workspace. The server verifies that the token is valid (authentication) but does not verify that the user has a role that permits sharing (authorization).

Since the endpoint runs on Butler's separate backend (app.butlerfortrello.com), it doesn't inherit Trello's role-based access control. Butler authenticates the user via its own token system, but it doesn't query Trello for the user's board role before processing the share action.

Same pattern as the board button bypass: If you read the earlier post about executing other users' private Butler buttons, this is the same architectural issue. Butler runs on a separate backend with its own auth layer. Trello enforces role restrictions (Observer can't share), but Butler's API doesn't check those restrictions. The UI hides the button; the API accepts the request anyway.

Exploitation

Prerequisites

Attacker role: Observer on the target board (the absolute lowest role)
Attacker has: A personal Butler automation library (can be created outside the board context)
Target: The workspace containing the board

Step 1: Create a Personal Automation Library

The Observer creates a personal automation library through Butler's personal automation management. This doesn't require any board-level permissions — it's a personal resource tied to the user's Butler account. The Observer can create rules like "move all cards to list X" or "archive all cards" — rules that would modify the board if ever executed.

Step 2: Send the Share Request

The Observer sends a direct API request to Butler's library-share endpoint using their own Butler API token:

HTTP Request — Observer Sharing Automation Library

POST /api/powerup-library-share HTTP/1.1
Host: app.butlerfortrello.com
Content-Type: application/json
X-Butler-Trello-Token: <OBSERVER-TOKEN>

{
  "board_id": "<TARGET-BOARD-ID>",
  "workspace_id": "<TARGET-WORKSPACE-ID>"
}

Response: 200 OK

The Observer's personal automation library is now shared with every member of the workspace — including board admins and the board owner. All the rules the Observer created appear in their shared library view.

Step 3: Wait for Import

The shared library now appears in the automation section for all board members and admins. If the board owner or any admin opens Automation > Libraries, they'll see the Observer's shared library listed alongside legitimate libraries. If they import it — which is a reasonable thing to do if they assume shared libraries come from trusted sources — all the Observer's automation rules get added to the board.

Once imported, the rules execute with the board's automation context. The Observer has effectively gained write access to a board they can only observe — not by directly modifying the board, but by planting automation rules that modify it on their behalf.

The social engineering angle: This isn't just a technical bypass — it has a social engineering component. The Observer creates a library named something innocuous like "Sprint Workflow Templates" or "Task Automation Best Practices." When the board owner sees a shared library with a professional name, they're likely to import it without scrutinizing every rule inside. The Observer's malicious rules (archive all cards, move cards to wrong lists, post spam comments) execute automatically once imported.

Bonus — Non-Board Members Can Share Too

While investigating, I discovered an additional dimension to this vulnerability: workspace members who haven't even joined the board can also share automation libraries targeting that board.

This works even when the board admin has explicitly disabled workspace editing for the board — a setting that prevents workspace members from joining or editing the board. Despite this restriction, a workspace member who is not a board member can still share automation libraries that appear in the board's library section.

Why is this worse? The original bug requires Observer access — at least someone had to intentionally add the attacker to the board (even in a read-only capacity). This extension means any workspace member can target any board in the workspace, even boards they've never been given access to and even boards that explicitly block workspace-level editing. The attack surface expands from "Observers on the board" to "anyone in the workspace."

Root Cause

The root cause is identical to the Butler board button bypass: Butler's API operates independently from Trello's role-based access control.

Pseudocode — Authorization Gap

// What Trello's UI checks (client-side)
function showLibraryShareButton(user, board) {
    const role = user.getRoleOnBoard(board);

    if (role === "observer") {
        return; // Don't show share button ✓ (UI restriction)
    }

    showShareToggle(); // Only for members and admins
}

// What Butler's API checks (server-side)
function handleLibraryShare(request) {
    const user = authenticateButlerToken(request.token);
    if (!user) return 401;

    // ✗ Missing: check user's role on the target board
    // ✗ Missing: check if user is even a member of the board
    // ✗ Missing: check workspace editing permissions

    shareLibraryWithWorkspace(user.library, request.workspace_id);
    return 200; // Shared with everyone
}

Butler's endpoint authenticates the user (valid token?) but doesn't authorize the action (does this user's board role permit sharing?). The UI hides the share button from Observers, but the API accepts the request from anyone with a valid Butler token and a board/workspace ID.

Impact

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

Privilege escalation: The lowest-privilege role (Observer) can perform an action restricted to higher-privilege roles (member/admin)
Indirect write access: If a privileged user imports the shared library, the Observer's rules execute on the board — giving the Observer effective write access through automation
Scope expansion: Non-board workspace members can also share libraries, extending the attack surface beyond actual board members
Trust exploitation: Shared libraries appear legitimate to board admins, creating a social engineering vector

The Observer role exists to guarantee read-only access. If an Observer can push automation rules that — when imported — modify the board, the read-only guarantee is broken. The role becomes "read-only unless someone imports my shared library."

Timeline

2022-06-08 — Original submission by another researcher
2024-12-05 — Independent rediscovery and submission by me (TechyCodec08)
2024-12-06 — Marked as duplicate of the June 2022 submission
No bounty awarded — duplicate submissions don't receive rewards
Fixed — the vulnerability has since been resolved

On duplicates: Finding a duplicate is frustrating — you do the same research, write the same detailed report, and get $0. But it's part of bug bounty. The upside: I independently found the same bug a veteran researcher found 2+ years earlier, which validates the methodology. And I found the bonus (non-board workspace members can also exploit it), which the original report may not have covered. Every duplicate sharpens your instincts for the next original find.

Takeaways

Always test the lowest-privilege role. Many hunters focus on normal member vs admin boundaries. The Observer role is often overlooked because "they can't do anything." Test every action from the Observer perspective — you'd be surprised how many features only check roles in the UI, not the API.
Separate backends = separate authorization. Butler runs on its own backend. It doesn't inherit Trello's RBAC. Every time you see a feature that calls a different backend (different domain, different API), test whether that backend independently checks user roles. It often doesn't.
Indirect write access is still write access. The Observer can't directly modify the board. But they can share automation rules that modify the board when imported. This "one hop removed" pattern — where the attacker can't do X directly but can set up conditions where X happens — is a powerful and often unrecognized attack vector.
Expand scope beyond the initial finding. After finding that Observers could share, I tested whether non-board workspace members could too. They could. Always push the boundaries of your finding: if role A can bypass, can role B? If board members can, can non-members? The extension often increases impact significantly.
Duplicates are educational, not failures. Write them up anyway. The research is the same whether you're first or second. Sharing the methodology helps others learn the same patterns — and the next variation of this bug might be original.