StampBleed
| CVE | Icon | Vulnerability name | Date | Responsible Security Disclosure by | Stars | Process | Vulnerabilities |
|---|---|---|---|---|---|---|---|
| - | StampBleed | 2026-10-27 | xet7 |  |
Found while reviewing a contributed patch for #6813, which would have relied on the stamp; fixed by xet7. |
A checklist, checklist item, text note or attachment inserted on one's own card could carry another board's id, and a checklist item another card's checklist id: a write into a private board without membership. CWE-639; high severity. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released. |
Details
Checklists, checklist items, text notes and attachments carry a denormalized board id: the board publication publishes them by it, with one reactive query per board. A checklist item also carries the id of its checklist, by which the checklist draws it. When a client inserted one of these documents, the server checked write access on the document's card only, and its insert hooks kept a board id the client had sent (they filled it from the card only when it was missing).
So any user - every user can create a board and be a member of it - could insert, on a card of their own board, a document stamped with a private board's id. It was published to that board's members. A checklist item could also name a checklist of the private board, and was drawn inside it. Board membership of the private board was not needed, only its ids.
The contributed patch for #6813 - a checklist item dragged on one's own board was reported as a cross-board attack - skipped the cross-board check for "the board the item is already on", read from this stamp. With a forged stamp that would have let an item be moved onto a card of the private board. The fix for #6813 reads the board from the item's card instead.
Fix: the server takes the board id from the card on insert, always (checklists, checklist items, text notes). An insert stamped with another board, or a checklist item naming another card's checklist, is refused - for a direct attachment insert too, by its meta.boardId. WeKan's own client never sends such an insert. Attachments uploaded through the upload pipeline are covered by UploadBleed.
Detection
A refused insert is recorded as StampBleed in Admin Panel / Problems (key authz.card-child-stamp), and the account that tried it is blocked, as for other high-severity attempts. Logging can never break the refusal.
Verification
tests/stampBleed.test.cjs runs the real refusal against stubs: the forged stamp and the foreign checklist are refused and recorded, and what WeKan's own client sends is neither refused nor recorded. A negative test fails on any card-child collection without an insert board check. tests/checklistSameBoardCanary6813.test.cjs reproduces the forged-stamp move the contributed patch would have allowed. A Playwright spec attacks the running server; it has not been run yet.