ReplyBleed
| CVE | Icon | Vulnerability name | Date | Responsible Security Disclosure by | Stars | Process | Vulnerabilities |
|---|---|---|---|---|---|---|---|
| - | ReplyBleed | 2026-09-30 | alex131125 |  |
Reported privately by alex131125 through GitHub Security Advisory GHSA-mc7c-cv99-64h7, with details and suggested remediation; validated and fixed by xet7. | The reply-by-email token in a notification's Reply-To address signed only the card, so every recipient of that card held the same address, and the webhook took the comment author from the reply's From field, which the sender controls. Anyone holding one card's reply address could have posted a comment on it as any user. Validation found that the webhook module was never imported by the server entry point, so released versions did not register The reply address now names the card and the one recipient, and expires (30 days by default). The author is that recipient, the From address must be one of that recipient's own addresses, and the recipient must still be allowed to comment on the card. An optional provider secret authenticates the mail provider. Addresses in the old card-only form are refused. CWE-346. Medium severity (CVSS 4.3). No CVE assigned. Fix prepared locally for the Upcoming release; not yet released. |
Details
Advisory GHSA-mc7c-cv99-64h7 reported that a reply to a notification email was attributed to whichever WeKan user owned the reply's From address. The reply token proved only that the address belonged to a card, not to whom it had been sent, so one recipient could reply as another, and anyone who saw a card's reply address could reply as anyone.
Reading the source confirmed the logic. It also showed that server/routes/inboundEmail.js had never been imported by server/imports.js: from the feature's introduction through v12.12, the running server did not register the endpoint, and no built bundle contained the handler. The documented feature did not work, and the flaw could not be reached. The fix registers the endpoint only together with the corrected checks.
Fix
The Reply-To address is now reply+<cardId>.<userId>.<expiry>.<mac>. The HMAC-SHA256 covers the card, the recipient and the last valid day, so none of them can be changed. The comment author is the recipient in the token. The reply is accepted only when its From address is one of that recipient's account addresses, the recipient is enabled, and their board role may comment on that card, including the assigned-only restriction. INBOUND_EMAIL_WEBHOOK_SECRET, when set, must be presented by the mail provider as a header or query value and is compared in constant time. The old card-only form is refused.
Detection
A forged token, a From address that is not the recipient's, and a missing or wrong provider secret are summarized as ReplyBleed in Admin Panel → Problems. Expired and pre-fix tokens, disabled users and members who have lost comment access are refused without a record, because real users replying to old mail reach them.
Verification
Unit tests cover the token round trip, per-recipient addresses, tampering with the card, the recipient or the expiry, expiry, and legacy tokens. The author decision reproduces the advisory's attack as data and covers disabled users, lost roles and the assigned-only restriction. A tree-wide negative test fails if any code chooses an author by searching users for a From address. A full-app test posts over HTTP to /api/inbound-email and checks spoofed senders, forged recipients, the genuine recipient, lost access, the provider secret and the Problems record. Multipart provider payloads are not parsed by WeKan's body parsers; JSON and URL-encoded payloads are.