Wekan CVE-2026-53445

Requires a valid authenticated Wekan account (PR:L) with network access to the DDP/WebSocket interface, and knowledge of the target's board ID (exposed in URLs and API responses, making it easily obtainable or enumerable). The specific trigger is calling the copyBoard Meteor DDP method directly rather than the REST POST /api/boards/:boardId/copy endpoint - the REST path correctly enforces board admin access and is NOT vulnerable, so exploitation is limited to the DDP method. Limiting factors: exploitation is impossible for fully unauthenticated users, is blocked on instances running 9.32+, and is constrained on deployments that disable self-registration (an attacker must first obtain an account). No non-default configuration is needed - the vulnerable DDP method is exploitable against default Wekan installs prior to 9.32.

The CVSS 4.0 base score is 7.1 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N - network-reachable, low complexity, requiring only low privileges (any authenticated account) and no user interaction, with high confidentiality impact and low integrity impact. The confidentiality impact is the real driver: an attacker gains full read access to otherwise private board contents by cloning them. No EPSS score, KEV listing, or POC was provided, so exploitation probability cannot be quantified; treat this as a plausible-but-unproven exploitation risk rather than confirmed active abuse. The main mitigating factor is that exploitation requires a valid authenticated account on the Wekan instance, which limits exposure on closed/invite-only deployments but is trivial on instances that allow self-registration. This is a genuine data-exposure priority for multi-tenant Wekan instances, not merely a high-CVSS-but-low-risk finding, though its real-world reach is bounded by Wekan's modest deployment footprint.

An attacker registers or already holds a low-privilege account on a shared Wekan instance, obtains or guesses the ID of a private board owned by another team (board IDs appear in URLs and API responses), and invokes the copyBoard DDP method with that ID. Because the method never checks membership or admin rights, the server clones the entire private board - including sensitive cards, custom fields, and rules - into a board the attacker controls, giving them full read access. No public exploit is identified, but the attack is a single authenticated DDP call and requires no user interaction.