WeKan
CVE-2026-25565
HIGH
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/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
Authenticated read-only board member (PR:L) exploits a network API with low complexity and no user interaction; impact is integrity-only (I:H), no confidentiality or availability effect, scope unchanged.
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:N/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
10DescriptionCVE.org
WeKan versions prior to 8.19 contain an authorization vulnerability where certain card update API paths validate only board read access rather than requiring write permission. This can allow users with read-only roles to perform card updates that should require write access.
AnalysisAI
Privilege escalation via broken authorization in WeKan (the open-source kanban board) before 8.19 lets users holding read-only board roles modify cards, lists, and swimlanes that should require write access. The flaw stems from card/list/swimlane update API routes calling a read-level access check instead of a write-level check, letting a low-privileged but authenticated member tamper with data they should only be able to view. There is no public exploit identified at time of analysis and EPSS is negligible (0.01%), but the fix is confirmed in an upstream commit and the CVSS 4.0 base score is 7.1.
Technical ContextAI
WeKan is a Meteor/Node.js self-hosted Trello-style kanban application; its REST API is defined in server-side model files (models/cards.js, models/lists.js, models/swimlanes.js, models/boards.js). The root cause is CWE-863 (Incorrect Authorization): the affected JsonRoutes handlers invoked Authentication.checkBoardAccess(), which merely confirms the caller can read the board, on endpoints that mutate state. WeKan's role model distinguishes several restricted member types (isReadOnly, isReadAssignedOnly, isCommentOnly, isNoComments, isWorker), and the correct gate must exclude all of them. The patch (commit 181f837) introduces Authentication.checkBoardWriteAccess(), which verifies the user is an active board member who is not read-only, read-assigned-only, comment-only, no-comments, or worker, and swaps it in across card update, card move (including destination-board validation), cards_count, list, and swimlane mutation routes; a related utils.js helper (allowIsAnyBoardMember) was also hardened to exclude read-only and no-comments roles. The affected package is identified by CPE cpe:2.3:a:wekan_project:wekan.
RemediationAI
Upgrade WeKan to version 8.19 or later, which incorporates the authorization fix (Authentication.checkBoardWriteAccess) applied in commit 181f837; this is the primary and recommended remediation. Patch details and the source fix are at https://github.com/wekan/wekan/commit/181f837d8cbae96bdf9dcbd31beaa3653c2c0285 and the advisory at https://www.vulncheck.com/advisories/wekan-read-only-board-roles-can-update-cards. If you cannot upgrade immediately, reduce exposure by auditing board memberships and removing or converting untrusted read-only/comment-only/worker members from sensitive boards, and by restricting network access to the WeKan API to trusted users so that only accounts you fully trust can reach the mutation endpoints; note the trade-off that this limits legitimate collaboration and does not close the flaw for any read-only user who retains access. Given the impact is integrity-only, also rely on board activity history to detect and roll back unauthorized card, list, or swimlane changes until the upgrade is applied.
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 weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today