WeKan CVE-2026-25563

Requires a valid authenticated WeKan account (CVSS PR:L) and network access to the WeKan checklist REST endpoints; no user interaction and no special non-default configuration is needed, as the missing card-belongs-to-board check was present in the default code path of all versions before 8.19. The concrete prerequisite is the ability to supply a cardId and boardId that reference different boards - the attacker must know or enumerate a valid cardId from another board. Exploitation is limited to integrity impact on checklist data (no confidentiality or availability effect per VC:N/VA:N) and is bounded by the need for authentication, so a purely single-user or trusted-tenant instance faces reduced practical risk.

Signals are internally consistent and point to a real but bounded authorization flaw rather than an urgent widespread threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows network-reachable, low-complexity, no-user-interaction exploitation but requires low-privilege authentication, and impact is integrity-only (VI:H) with no confidentiality (VC:N) or availability (VA:N) effect and no scope/subsequent-system impact - matching the diff, which guards writes into other boards without exposing read access. EPSS is near-floor (0.01%, 1st percentile) and there is no KEV listing and no public exploit identified at time of analysis, so this is not under active exploitation. The main priority driver is that it needs only a valid (any) authenticated WeKan account, making it a plausible insider/multi-tenant abuse vector; on a single-tenant private instance the practical risk is lower. No SSVC decision data was provided in the input, so automatable/technical-impact SSVC classification cannot be stated.

An attacker registers or already holds an ordinary WeKan account, then calls the checklist creation REST route supplying the boardId of a victim board together with a cardId from a different board they can enumerate. Because the server never checked that the card belongs to that board, the checklist write succeeds, letting the attacker inject or alter checklist content on cards outside their authorization. No user interaction is needed and attack complexity is low, but valid authentication is required and there is no public exploit identified at time of analysis.