ListLockBleed
| CVE | Icon | Vulnerability name | Date | Responsible Security Disclosure by | Stars | Process | Vulnerabilities |
|---|---|---|---|---|---|---|---|
| - | ListLockBleed | 2026-11-09 | tsurutanmen |  |
Reported privately by tsurutanmen through GitHub Security Advisory GHSA-4734-8vrg-8j3w, from a read-only review of the source with the affected lines and a suggested fix; validated and fixed by xet7. |
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 and comment REST routes and the DDP checklist methods applied that rule. The six checklist and checklist-item REST routes did not: they checked only the board's write capability. So a member the list refused, holding an API token, could still add, rename and delete the checklists and items of that list's cards, and tick or untick the items. Nothing outside the board was reached, and the member already had write access to the rest of the board.
Fix: after the board and card checks, the POST, PUT and DELETE routes for checklists and checklist items also call assertListNotRefused with the card's list, as the card routes do, and answer 403. A refused call changes nothing.
Detection
A refusal is recorded in Admin Panel / Problems as ListLockBleed (key authz.list-locked). The interface never offers a 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/listPermissions.test.cjs scans every REST write route of the tree that names a card and fails on one that does not ask the card's list. It also checks that the refusal is recorded. tests/playwright/specs/list-lock-checklists.e2e.js replays all six writes 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.