RelayBleed
| CVE | Icon | Vulnerability name | Date | Responsible Security Disclosure by | Stars | Process | Vulnerabilities |
|---|---|---|---|---|---|---|---|
| - | RelayBleed | 2026-10-02 | xet7 |  |
Found while auditing outbound requests after SyncBleed; fixed by xet7. | The live Trello import downloaded attachments, the board background and member avatars with the importing user's Trello API key and token in an OAuth header, whatever host the URL named. A link attachment's URL is chosen by anyone who can edit the Trello board, and one renamed to look like a file was downloaded like an upload, so its host received the importer's token. The background and avatar downloads retried with the token after a public download failed. The credential now goes only to Trello's own HTTPS hosts; every other download goes without it. CWE-201, CWE-522. High severity: it needs the victim to import a board the attacker can add an attachment to. No CVE assigned. Fix prepared locally for the Upcoming release; not yet released. |
Details
Reviewing every outbound request after SyncBleed showed that the live Trello import, which downloads files server-side so they can be stored in WeKan, attached the importing user's Trello key and token to every download. Trello needs that credential for files uploaded to Trello, and WeKan sent it everywhere. The only filter skipped a link whose name equalled its URL, and Trello lets a link be renamed, so a link named like a file and pointing at another host was downloaded with the credential. The SSRF guard already refused internal addresses and dropped the header on a redirect off the origin, but the first request went straight to the named public host. Background and avatar downloads tried without the credential first and retried with it.
Whoever can add an attachment to a Trello board that someone later imports into WeKan - a member of a shared board, for example - could collect that person's Trello token, which acts for them on Trello within its scope.
Fix
The OAuth header is built in one place, and only for HTTPS to trello.com and api.trello.com on the default port. Every other attachment, background or avatar is downloaded without it, and the background and avatar retries with the credential happen only for those hosts.
Detection
None. A link attachment on another host is ordinary board content, so withholding the credential happens on normal imports and is not an attempt to record in Admin Panel → Problems.
Verification
Unit tests run the real import code with the network stubbed and record which hosts receive the credential: an uploaded Trello file does, a renamed link and Trello lookalikes (another port, plain HTTP, a longer host name) do not, and the background and avatar retries follow the same rule. A negative test fails if the credential header is built anywhere else in the server. The live import always calls the fixed Trello API, so there is no browser test.