Wekan

Reported privately in GHSA-mc7c-cv99-64h7 (CWE-346, CVSS 4.3). The reply-by-email token signed only the card, so every recipient of a card’s notification held the same Reply-To address, and the webhook took the comment author from the reply’s From address - a field the sender controls. Anyone holding one card’s reply address could comment on it as any user.

Validation also found that server/routes/inboundEmail.js was never imported by server/imports.js, so released versions did not register /api/inbound-email: the documented feature did not work and the flaw could not be reached. The endpoint is registered now, together with the fix.

• The reply address is reply+<cardId>.<userId>.<expiry>.<mac>, an HMAC-SHA256 over the card, the recipient and the last valid day (INBOUND_EMAIL_REPLY_DAYS, default 30).
• The author is that recipient. The From address must be one of the recipient’s own addresses, and the recipient must be enabled and still allowed to comment on the card, including the assigned-only restriction.
• INBOUND_EMAIL_WEBHOOK_SECRET, when set, must be presented by the provider as the X-WeKan-Inbound-Secret header or ?secret=. It is compared in constant time.
• The old card-only token is refused.
• A forged token, a spoofed sender and a wrong provider secret appear as ReplyBleed in Admin Panel → Problems. Expired and pre-fix tokens and lost access are refused without a record, because real users replying to old mail reach them.

Unit tests cover the token and reproduce the advisory’s attack as data. A tree-wide negative test fails if any code picks an author from a From address. A full-app test posts over HTTP to the endpoint. Multipart provider payloads are still not parsed; JSON and URL-encoded ones are.