Wekan EUVD-2026-42935

Exploitation requires all of the following: (1) an authenticated Wekan user account with write access to at least one board on the target Wekan instance; (2) prior knowledge of a valid card ID belonging to a card on a private board the attacker is not a member of - this card ID must be obtained through separate means such as prior board membership, social engineering, or another information disclosure path; (3) the ability to send crafted Meteor DDP WebSocket messages, achievable through browser developer tools or a DDP client library, requiring no special tooling. The impact is strictly bounded to unauthorized data writes - the attacker cannot read private board content, escalate to administrative roles, or affect availability. The flaw is present in default Wekan deployments without any special configuration required to be vulnerable; there is no feature flag or non-default setting that enables or disables the vulnerable code path.

The CVSS 3.1 score of 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N is a reasonable characterization of a constrained impact: only integrity is degraded (unauthorized checklist data written to a private board), with no confidentiality or availability effect. The PR:L requirement is accurate - exploitation is gated behind authenticated session access and write permissions on at least one existing board. Notably, the attack also requires prior knowledge of a private target card ID, a reconnaissance prerequisite that arguably pushes real-world complexity higher than AC:L implies, though the vendor's advisory does not elevate complexity. No EPSS score was included in the provided intelligence. No CISA KEV listing exists and no public proof-of-concept code is known, meaning automated or opportunistic exploitation is not a present concern. SSVC framing: exploitation status is 'none publicly known', the attack is not obviously automatable at scale without card ID enumeration, and technical impact is partial integrity only - together yielding a low-urgency remediation priority except in deployments with sensitive private boards containing confidential planning data.

An authenticated Wekan user with write access to a shared project board discovers the card ID of a card on a confidential executive planning board (obtained via prior access, a leaked URL, or enumeration) and crafts a Meteor DDP update message that creates a ChecklistItem on one of their own accessible cards while embedding the private board's cardId as the destination in the update modifier. The allow rule passes because the source authorization check succeeds, and Wekan writes the checklist data to the private board - potentially contaminating or polluting it with attacker-controlled content without the private board's members being aware of the unauthorized write.