Wekan CVE-2026-53447

The attacker must hold a valid authenticated session on the target Wekan instance (CVSS PR:L confirmed). The attacker must know or be able to infer the MongoDB _id of the target private board - this value is not a cryptographic secret but is not surfaced in the Wekan UI to non-members; it can leak through URL sharing, referrer headers, or API enumeration. No special server configuration or non-default feature flag is required; the cloneBoard method is a core Wekan feature present in all pre-9.35 deployments. Exploitation is bounded to users with a valid account on the same Wekan instance as the target board - unauthenticated external attackers cannot exploit this flaw directly. The absence of integrity and availability impact limits the blast radius to confidential data exposure.

The NVD CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is accurate and well-calibrated. Attack complexity is genuinely low: the only barrier beyond authentication is obtaining a target board's MongoDB _id, which - while not advertised in the UI - can leak through browser history, shared URLs, referrer headers, or API responses in a multi-tenant deployment. The confidentiality impact is high because the exporter returns a complete board snapshot. There is no integrity or availability impact. This vulnerability is not listed in CISA KEV and no public exploit code has been identified at time of analysis; EPSS data was not provided. For multi-tenant, internet-facing Wekan deployments the real-world risk is elevated - any regular account holder becomes a threat to all private boards on the instance. For internally-deployed, single-team instances the practical risk is lower, as exploitation requires insider access. No conflicting signals exist between CVSS and the description; the vector is consistent with the actual attack mechanics.

An authenticated Wekan user discovers the MongoDB _id of a private board belonging to another team - obtained, for example, from a URL in shared browser history, a Slack message, or an API response - and sends a DDP call to the cloneBoard Meteor method with that ID as the sourceBoardId parameter. The server processes the request without invoking any membership check, exports the full board, and creates a copy in the attacker's workspace, granting them persistent read access to all cards, comments, attachments, member identities, and activity logs. No public exploit code has been identified, but any developer with Meteor DDP knowledge can reproduce this with standard tooling.