WeKan
CVE-2026-25565
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain read-only membership on a board
-
DeliveryAuthenticate to WeKan API
-
ExploitSend crafted card/list/swimlane update request
-
ExecutionRead-level check passes on write route
-
ImpactModify or move data without write rights
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The attacker must be an authenticated WeKan user who is an active member of the target board holding a restricted, non-write role (isReadOnly or isReadAssignedOnly, and analogously comment-only/no-comments/worker for related endpoints) - i.e., someone deliberately given read-level access. Exploitation targets the card update, card move/cards_count, list, and swimlane REST API routes that used checkBoardAccess instead of checkBoardWriteAccess. Limiting factors: the attacker needs valid credentials and an existing board membership (PR:L, not unauthenticated), impact is restricted to integrity of board data with no confidentiality or availability effect, and deployments that never grant read-only roles to untrusted users are not practically exposed. |
| Impact | The signals are internally consistent and point to a real but bounded integrity issue rather than a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows network-reachable, low-complexity exploitation requiring low privileges - the attacker must already be an authenticated, invited board member with a read-only role - and impact is confined to integrity (VI:H) with no confidentiality (VC:N) or availability (VA:N) effect and no scope change (SC/SI/SA:N). EPSS is very low at 0.01% (1st percentile) and the vulnerability is not in CISA KEV, so there is no evidence of active or widespread exploitation; this is expected for an authorization bug that requires prior authenticated access to a shared board rather than a mass-exploitable pre-auth flaw. No SSVC record or POC was provided. The main caveat is the required foothold: exploitation presupposes an attacker who has been granted a restricted role on a board, so real-world risk concentrates in multi-tenant or collaborative deployments where untrusted or limited-trust users are given read-only access. Overall this is a legitimate patch-in-normal-cycle item, not a drop-everything issue. |
| Exploit ScenarioDerived | An organization grants an external collaborator or a low-trust internal user a read-only role on a WeKan board so they can view progress but not change it. Because the card/list/swimlane update endpoints only checked read access, the user sends a crafted authenticated API request (AV:N/AC:L/PR:L) to edit, move, or alter cards - for example rewriting card content or moving a card to another board - silently corrupting the board's data. No user interaction or elevated privileges beyond their existing read-only membership are needed; no public exploit is identified at time of analysis, but the fix diff makes the vulnerable endpoints obvious. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv4 – Jul 14, 2026
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.
Earlier versions of this analysis (3)
Improper authorization in WeKan before 8.19 lets authenticated users holding read-only board roles perform write operations (card, list, and swimlane updates) that should be denied. The affected REST API paths called Authentication.checkBoardAccess (a read gate) instead of a write-access check, so any active board member - including read-only, comment-only, and read-assigned roles - could tamper with board content. EPSS is 0.01% and there is no public exploit identified at time of analysis; this is a low-noise authorization/integrity defect rather than an actively exploited flaw.
Improper authorization in WeKan before 8.19 lets authenticated users holding read-only board roles perform card, list, and swimlane update operations that should require write permission. Multiple REST API paths validated only board read access (checkBoardAccess) instead of write access, enabling unauthorized modification and cross-board card moves. EPSS is very low (0.01%, 1st percentile) and there is no public exploit identified at time of analysis, but a vendor patch is available.
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. [CVSS 6.5 MEDIUM]
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.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when Wekan gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
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
Lifecycle Timeline
7DescriptionCVE.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.
Executive ViewAI
WeKan kanban board deployments before version 8.19 allow authenticated users with read-only access to modify board data-cards, lists, and swimlanes-that should remain restricted, compromising data integrity and audit trail reliability. This affects organizations relying on WeKan for task management and project visibility, where role-based access controls are fundamental to compliance and operational governance. An authenticated board member can escalate privileges within their assigned boards without triggering detection.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
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
Privilege escalation in Wekan open-source kanban (all versions prior to 9.89, dubbed 'SortBleed') allows any board membe
Privilege escalation in the self-hosted Wekan kanban board through version 18.15 allows any authenticated user to rewrit
Stored XSS in Wekan prior to v9.90 allows authenticated board members to upload HTML containing JavaScript disguised as
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
Wekan's outgoing webhook URL validator in versions 8.36 through 9.73 allows authenticated board members to bypass SSRF p
Exploit-DB