HookBleed

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

CVE	Icon	Vulnerability name	Date	Responsible Security Disclosure by	Stars	Process	Vulnerabilities
-		HookBleed	2026-10-02	xet7		Found while auditing outgoing board webhooks after the 2026-10-02 Hall of Fame review; fixed by xet7.	The `outgoingWebhooks` method built its request from the integration object the CALLER sent - which decided whether the hook was two-way and carried the token - and from the caller's own description and parameters. Any board member, read-only included, could post any text to the board's Slack, Matrix or other chat webhook as WeKan, without a limit, or make a one-way hook two-way so that its answer rewrote comments. The request is now built from the stored integration. From a client only the card-opened notification is allowed, and its parameters are rebuilt on the server from a card on that board. CWE-345. High severity: any member of a board with a webhook. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released.

HookBleed

2026-10-02

xet7

Found while auditing outgoing board webhooks after the 2026-10-02 Hall of Fame review; fixed by xet7.

The outgoingWebhooks method built its request from the integration object the CALLER sent - which decided whether the hook was two-way and carried the token - and from the caller's own description and parameters. Any board member, read-only included, could post any text to the board's Slack, Matrix or other chat webhook as WeKan, without a limit, or make a one-way hook two-way so that its answer rewrote comments.

The request is now built from the stored integration. From a client only the card-opened notification is allowed, and its parameters are rebuilt on the server from a card on that board.

CWE-345. High severity: any member of a board with a webhook. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released.

Details

The client calls outgoingWebhooks when a card is opened, so the board's chat hook can say so. The server method trusted the integration object in the call: its type decided whether the hook was two-way, and its token was sent. The text and the parameters came from the caller too.

So any member of the board - read-only members included - could send any message to the board's Slack, Matrix or other webhook, appearing to come from WeKan, as often as they liked. Calling it with the type set to two-way made the server treat the hook's answer as an edit of the board's comments.

Fix

The request is built from the integration stored for the board, never from the caller's copy. A client may only trigger the card-opened notification, and its parameters are rebuilt on the server from a card that is on that board.

Detection

A client call that asks for anything but the card-opened notification, or names a card that is not on the board, is refused and summarized as HookBleed in Admin Panel → Problems (catalog key ssrf.webhook-forge).

Verification

Unit tests in tests/webhookPreparation.test.cjs check that a client cannot forge what a board webhook sends, together with the existing tests that preparation freezes endpoint, token and parameters and that suppressed or denied deliveries never send; tests/activityPayloadValues.test.cjs checks the payload still carries every configured value. The browser test tests/playwright/specs/hook-bleed.e2e.js tries to send a member's own message through a board webhook. The unit tests pass in the WeKan repository. The browser test was not run for this page.

Source fix and regression tests