| CVE | Vulnerability name | Date | Responsible Security Disclosure by | Vulnerabilities |
|---|---|---|---|---|
| GHSA-f396-42fx-vr88 GHSA-3cgr-47wm-9cc9 GHSA-r4gm-mjj9-g3x8 |
AssignedBleed |
2026-08-21 |
Char0n1507,
crypto-nidh,
binary-lover and
xet7
Coordinated disclosure with a working reproduction and root-cause analysis. |
|
The shared REST helper Authentication.checkBoardWriteAccess()
decided write access with a handwritten list of excluded member flags. It
excluded Comment Only, Worker and both read-only roles, but omitted
isCommentAssignedOnly. The canonical board-role table gives
Only Assigned Comment write: false, yet every mutation route
using the REST helper treated that member as a writer.
The issue was reproduced against WeKan v11.06 by having an authenticated
Only Assigned Comment member send PUT
/api/boards/:boardId/lists/:listId/cards/:cardId for an unassigned
card. The endpoint returned HTTP 200 and persisted the supplied title. A
Comment Only member was correctly refused as a control.
Fix: the shared REST helper now calls
allowIsBoardMemberWithWriteAccess(), the same canonical
capability decision used by DDP permissions and the client. This protects
every card mutation route and every other REST write route using the helper.
Both parallel attachment API implementations now use it as well.
Comment Only, Only Assigned Comment, Worker, Read Only and Only Assigned Read are denied. Board Admin, Normal, Normal Assigned Only and No Comments retain access. Denied attempts are rate-limited, attributed and visible in Admin Panel → Problems under AssignedBleed.
| Timeline | Details |
|---|---|
| 2026-08-21 | Report received from Char0n1507 through GitHub Security Advisory GHSA-f396-42fx-vr88. |
| 2026-08-21 | Fixed for the upcoming WeKan release. |
| 2026-10-15 | Follow-up report received from crypto-nidh through GitHub Security Advisory GHSA-3cgr-47wm-9cc9, validated against the current source and fixed for the upcoming WeKan release. |
| 2026-10-16 | Follow-up report received from crypto-nidh through GitHub Security Advisory GHSA-r4gm-mjj9-g3x8, validated against the current source and fixed for the upcoming WeKan release. |
Assigned-only members' read paths still showed every card of the board: the attachment API (REST and method list, download and info), the activities publication, Due Cards with all users, Global Search, the structural move pickers and position history asked only for board membership. Each now applies the same assigned-only rule as the board publication, and a download or info request for another card's attachment is recorded under AssignedBleed in Admin Panel → Problems. Fix.
The REST board access check behind the routes that return whole-board data counted the assigned-only roles as full readers, so such a member's API client read every card. They are refused there now; it is not recorded, because their client reaches it in ordinary use. Fix.
Copying or moving cards, lists and swimlanes out of a board checked only membership of the source board. An assigned-only member may now copy a card assigned to them, and no list or swimlane. Fix.
A copy of a card carried every subtask of it. An assigned-only member who copied a card assigned to them got copies of its subtasks assigned to others, and any member got copies of its subtasks on boards they cannot read, since a parent may have subtasks on another board. A copy now carries only the subtasks the copier could read and copy themselves, in the copy dialog and in rules alike. It is not recorded in Admin Panel → Problems: copying a card with subtasks is ordinary use. Fix.
Reported by crypto-nidh in GHSA-3cgr-47wm-9cc9: the 2026-10-02 fix reached the attachment API, but six other paths still asked an assigned-only member only for board membership. The /cdn/storage/attachments and /cfs/files/attachments downloads, the Attachments.protected check and the legacy download route served the file of any card; the document text search returned the extracted text of every card's PDF, DOCX, XLSX and PPTX files with their attachment and card ids; the legacy attachments publication listed every legacy file of the board; and a linked list showed every card of its source list. Each now applies the same rule. A refused download, or a subscription to another card's legacy files, is recorded under AssignedBleed in Admin Panel → Problems; searching and viewing a linked list are ordinary use and are narrowed without a record. The board's own background and map image stay readable to every member. Fix.
Reported by crypto-nidh in GHSA-r4gm-mjj9-g3x8: the Board Email View checked only that the reader was a board member, so an assigned-only member read the title, description and email metadata of every card in a list or label, and their counts. Board role permissions now apply to every board view and every path to a card. An audit found the same shape in the board publication's parent and linked cards and comment reactions, the All Boards counts, linked boards' activities, the Chat view and All Boards feed (which also let card members through), the notification publications, position history, the cross-board subtask picker and REST - and in writes, where the role's write permission let such a member change, comment on, move or watch any card by id. Each now asks the card; REST writes refuse assigned-only members, as REST reads already did. Attempts no view would make are recorded under AssignedBleed in Admin Panel → Problems. Fix.