RepointBleed

CVE Icon Vulnerability name Date Responsible Security Disclosure by Stars Process Vulnerabilities

CVE	Icon	Vulnerability name	Date	Responsible Security Disclosure by	Stars	Process	Vulnerabilities
-		RepointBleed	2026-10-02	xet7		Found while auditing board-owned rule and webhook documents after the 2026-10-02 Hall of Fame review; fixed by xet7.	Rule triggers, actions, rules and webhook integrations could be updated by an admin of the board the document was on before the update, and nothing refused an update that changed that board. Any registered user, as admin of a board they created, could move a rule trigger to `'*'` or unset its board - which the rule matcher matched on every board - and have a send-email action mail them cards, comments and attachments from every private board; or move a webhook integration onto a private board and receive its activity, or rewrite its comments through a two-way hook. Custom fields accepted a board list when the caller could write any one board in it, and a comment reaction could be moved to another comment. A client update can no longer change the board of these documents, custom fields need write access on every board added or removed, and the rule matcher runs a rule only for activity on its own board. CWE-863. High severity: anyone who can register can create a board and become its admin. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released.

RepointBleed

2026-10-02

xet7

Found while auditing board-owned rule and webhook documents after the 2026-10-02 Hall of Fame review; fixed by xet7.

Rule triggers, actions, rules and webhook integrations could be updated by an admin of the board the document was on before the update, and nothing refused an update that changed that board. Any registered user, as admin of a board they created, could move a rule trigger to '*' or unset its board - which the rule matcher matched on every board - and have a send-email action mail them cards, comments and attachments from every private board; or move a webhook integration onto a private board and receive its activity, or rewrite its comments through a two-way hook. Custom fields accepted a board list when the caller could write any one board in it, and a comment reaction could be moved to another comment.

A client update can no longer change the board of these documents, custom fields need write access on every board added or removed, and the rule matcher runs a rule only for activity on its own board.

CWE-863. High severity: anyone who can register can create a board and become its admin. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released.

Details

Rule triggers, actions, rules and webhook integrations belong to a board, and their client update rules asked whether the caller was an admin of the board the document was on. That is the board BEFORE the update; nothing looked at the board the update moved it to. A board admin is anyone who has created a board, so any registered user could take a trigger of their own board and set its boardId to '*', or unset it. The rule matcher treated both as matching every board, so a rule whose action sends email ran for activity on every board of the server and mailed its owner the cards, comments and attachments of private boards they were never a member of.

Webhook integrations had the same fault: moving one onto a private board delivered that board's activity to the attacker's URL, and a two-way hook's answer could rewrite the board's comments. Custom fields carry a list of boards and accepted a new list when the caller could write any one board in it, so a field could be attached to a board the caller could not write. A comment reaction could be moved onto another comment.

Fix

One shared deny rule refuses a client update that changes the board of a trigger, action, rule or integration, and a comment reaction can no longer be moved to another comment. A custom field's board list may change only when the caller can write every board added and every board removed. The rule matcher runs a rule only for activity on the rule's own board, so a trigger stored before the fix with '*' or no board matches nothing.

Detection

A refused board change is summarized as RepointBleed in Admin Panel → Problems (catalog key authz.repoint), with who, how often and since when.

Verification

Unit tests in tests/repointBleed.test.cjs reproduce the reported attack - moving a trigger or a webhook to another board is refused and recorded - and cover custom fields and comment reactions, and check that the matcher keeps a rule on its own board. The negative test fails on any board-owned collection with a client update rule that does not refuse a board change. The browser test tests/playwright/specs/repoint-bleed.e2e.js tries to move triggers, webhooks and custom fields from a signed-in client. The unit tests pass in the WeKan repository. The browser test was not run for this page.

Source fix and regression tests

Follow-up fix (2026-10-03)

A board admin could still save a rule on their own board that named a trigger of another board. Only that board's own rules ran on its activities, but the matcher took a trigger's rule from whichever rule named it first, so the other board's own rule could silently stop running. The matcher now looks up the rule on the activity's own board, and a rule naming another board's trigger is refused and summarized as RepointBleed in Admin Panel → Problems. Fix.