ListLockAttachBleed
| CVE | Icon | Vulnerability name | Date | Responsible Security Disclosure by | Stars | Process | Vulnerabilities |
|---|---|---|---|---|---|---|---|
| - | ListLockAttachBleed | 2026-11-11 | Furkan Derse |  |
Reported privately by Furkan Derse by email, with the affected lines, a proof of concept and a suggested fix; validated and fixed by xet7. The report arrived without a GitHub Security Advisory: the researcher will add one when GitHub's advisory creation limit allows, and the GHSA is awaited. |
When a board admin refused a role write access in one list ( |
Details
A board admin can give a list its own rule for a role (list.roleExceptions, #4527): for example, Normal members may read a list but not write in it. The card screen, the card and checklist routes (ListLockBleed) and the interface's own attachment upload and delete applied that rule. The attachment API did not: POST /api/attachment/upload, DELETE /api/attachment/delete/:attachmentId, POST /api/attachment/copy, POST /api/attachment/move and their DDP methods api.attachment.upload, .delete, .copy and .move asked for the board's write capability and mayWriteCardAttachment, which for a member who is not assigned-only allows every card. So a normal member the list refused, holding an API token or a session, could still add files to that list's cards, delete theirs, and copy or move files onto and off them. Nothing outside the board was reached, and the member already had write access to the rest of the board.
Fix: every attachment write that names a card also asks mayWriteInCardList with that card (server/lib/assignedOnlyAttachments.js), beside the board and assigned-only checks, and answers 403 (REST) or not-authorized (DDP). A move asks both the card it takes the file from and the card it puts it on. The card's own board decides, whatever board the caller named. As for the REST card routes, only a list's refusal counts: a list's grant does not open the API to a role the board does not let write. A refused call changes nothing.
Detection
A refusal is recorded in Admin Panel / Problems as ListLockAttachBleed (key authz.list-locked-attachment), with the refusing route as its source. The interface never offers an attachment write in a list that refuses it, so only a direct API call reaches the refusal. Medium severity in Problems: it never disables the account.
Verification
tests/listLockAttachments.test.cjs runs the guard itself on the reporter's board, a normal member and a list refusing normal.write, for all eight routes. It checks the negative cases (an open list, a granting list, the board admin, a board-level file, a caller naming another board) and the record in Problems. It also scans the whole tree, so that every mayWriteCardAttachment call is paired with the list check under the same source. tests/playwright/specs/list-lock-attachments.e2e.js replays upload, delete, copy and move, and the DDP delete, against a running server: in a locked list they are refused and change nothing; in an open list the same member writes, and the board admin writes in the locked one.