Wekan CVE-2026-55234

The attacker must be an authenticated Wekan user (PR:L) who has write access to at least one board they control, and must issue a raw DDP update to /cards/update, /lists/update, or /swimlanes/update with a new destination boardId placed in the update modifier's $set. The destination must be a valid boardId (a private board the attacker is not a member of) - exploitation targets integrity of that destination board rather than reading its contents. Limiting factors: it is not remote-unauthenticated (a valid account with a writable board is required), it requires a client capable of sending arbitrary DDP modifiers rather than the standard UI, and it is neutralized entirely on Wekan 9.37+ where the destination board's write access is validated.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L, base 8.5) is internally consistent with the description: network-reachable DDP endpoint, low complexity, low privileges (an ordinary authenticated user with one writable board), no user interaction, and a scope change because the impact crosses into a board outside the attacker's authorization. Impact is integrity-centric (I:H) - unauthorized content injected into a private board - with minor availability effect (A:L) and no direct confidentiality loss (C:N), since the attacker pushes data in rather than reading the private board out. No EPSS score, KEV entry, or POC was supplied, so exploitation probability signals are absent; this is a genuine but bounded authorization flaw rather than a mass-exploitation candidate. The main caveats: the attacker must already hold a valid account with write access to at least one board, and the flaw enables data-placement/integrity abuse rather than data theft or code execution - so real-world priority is moderate-to-high for multi-tenant Wekan instances and lower for single-user or trusted-team deployments.

An attacker registers or already holds a normal Wekan account and creates or is granted write access to their own board. Using a crafted DDP call to /cards/update (or /lists/update, /swimlanes/update) they set a new boardId in the update modifier pointing at a private board they are not a member of; the source-board-only allow check passes and the card/list/swimlane is relocated into the victim's private board. No public POC is referenced, but the fixing commit fully describes the bypass, and the low complexity plus no user interaction make reproduction straightforward.