WeKan
CVE-2026-25564
HIGH
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network REST API with low complexity and no interaction, but a low-privileged account is required (PR:L); IDOR tampers with/deletes checklists giving I:H and A:L, with no data disclosure (C:N).
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
9DescriptionCVE.org
WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in checklist creation and related checklist routes. The implementation does not verify that the supplied cardId belongs to the supplied boardId, allowing cross-board ID tampering by manipulating identifiers.
AnalysisAI
Cross-board data tampering in WeKan (open-source Trello-style kanban board) before version 8.19 lets an authenticated low-privileged user manipulate checklists on cards belonging to boards they should not access. The checklist creation, deletion, and related REST routes accept a cardId without confirming it belongs to the supplied boardId, so an attacker can forge identifiers to add or remove checklists on other users' cards. No public exploit identified at time of analysis, and EPSS is negligible (0.01%), but the vendor fix commit confirms the root cause and a straightforward exploitation path.
Technical ContextAI
WeKan is a Meteor/Node.js kanban application whose server-side REST API (models/checklists.js) exposes routes keyed by boardId, cardId, and checklistId. The flaw is a classic CWE-639 Authorization Bypass Through User-Controlled Key (IDOR): the handler trusted the caller-supplied cardId and never validated the parent-child relationship between board, card, and checklist. The vendor fix (commit 08a6f084) adds two ReactiveCache lookups - one confirming the card's _id is scoped to the requested boardId, and one confirming the checklist's _id is scoped to that cardId - returning HTTP 404 when the relationship does not hold. The single CPE cpe:2.3:a:wekan_project:wekan covers all pre-8.19 builds.
RemediationAI
Vendor-released patch: upgrade WeKan to version 8.19 or later, which incorporates fix commit 08a6f084 adding card-to-board and checklist-to-card relationship validation on the affected checklist routes (see https://github.com/wekan/wekan/commit/08a6f084eba09487743a7c807fb4a9000fcfa9ac). If immediate upgrade is not possible, reduce exposure by restricting who holds accounts on the instance and by limiting network reachability of the WeKan API to trusted users (e.g. VPN or reverse-proxy access controls), since exploitation requires an authenticated low-privileged session; be aware this does not fix the underlying IDOR and only shrinks the attacker population. Review board membership and audit checklist changes for signs of tampering. Consult the VulnCheck advisory (https://www.vulncheck.com/advisories/wekan-checklist-deletion-idor-via-missing-relationship-validation) for endpoint-specific details.
packages/wekan-ldap/server/ldap.js in Wekan before 4.87 can process connections even though they are not authorized by t
OS command injection in Wekan (the open-source Meteor-based kanban board) before version 9.07 lets an authenticated user
Authentication bypass in Wekan (open-source Meteor kanban) before version 9.46 lets an unauthenticated attacker imperson
A stored cross-site scripting (Stored XSS) vulnerability in file preview in WeKan before 6.75 allows remote authenticate
Wekan, open source kanban board system, between version 3.12 and 4.11, is vulnerable to multiple stored cross-site scrip
Account takeover in Wekan (open-source Meteor kanban) before 9.32 allows an attacker who controls an OIDC provider accou
LDAP filter injection in WeKan before 8.19 allows remote unauthenticated attackers to manipulate LDAP search filters and
Privilege escalation in WeKan (versions prior to 8.35) allows authenticated board members with low privileges to perform
Improper access control in Wekan (self-hosted open-source Meteor kanban) before version 9.37 lets any authenticated user
Wekan versions 8.31.0 through 8.33 expose webhook URLs and authentication tokens to all board members through unfiltered
Server-Side Request Forgery in Wekan 8.32-8.33 allows authenticated users to force the server to make arbitrary HTTP req
Privilege escalation in Wekan (self-hosted Meteor kanban) before 9.32 lets any authenticated user directly invoke OIDC-o
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today