What is the CVSS score of CVE-2026-55234?

CVE-2026-55234 has a CVSS 3.1 base score of 8.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L. EPSS exploitation probability: 0.2%.

Which versions of Wekan are affected by CVE-2026-55234?

Wekan before version 9.37 contains an improper access control vulnerability that allows any authenticated user with write permissions to relocate cards, lists, and swimlanes into private boards they…

How to fix or mitigate CVE-2026-55234?

Within 24 hours, identify all Wekan deployments in your environment and classify which boards store confidential or business-critical data; document current user permissions and assess exposure scope if the vulnerability were exploited. Within 7 days, schedule and validate an upgrade plan for Wekan version 9.37 or later by testing in a non-production environment to confirm compatibility and proper function of access controls. Within 30 days, complete deployment of Wekan version 9.37 or later across all production instances and verify via functional testing that private boards are properly isolated and user write permissions respect destination board boundaries.

Wekan CVE-2026-55234

HIGH

Improper Access Control (CWE-284)

2026-07-15 GitHub_M

Authentication Bypass Wekan

8.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.5 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L

vuln.today AI

8.5 HIGH

Authenticated user with write access to one board gives PR:L; network DDP endpoint and simple modifier give AV:N/AC:L; crossing into an unauthorized board is a scope change (S:C) with integrity injection (I:H) and no read (C:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:L/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

None

Integrity

High

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jul 15, 2026 - 22:04 vuln.today

Analysis Generated

Jul 15, 2026 - 22:04 vuln.today

CVE Published

Jul 15, 2026 - 21:13 cve.org

HIGH 8.5

DescriptionCVE.org

Wekan is open source kanban built with Meteor. Prior to 9.37, Wekan DDP update allow rules in server/permissions/cards.js, server/permissions/lists.js, and server/permissions/swimlanes.js authorize against the stored source boardId and do not validate a new boardId in the update modifier. Any authenticated user with write access to their own board can call /cards/update, /lists/update, or /swimlanes/update to move cards, lists, or swimlanes into a private board they are not a member of. This issue is fixed in version 9.37.

AnalysisAI

Improper access control in Wekan (self-hosted open-source Meteor kanban) before version 9.37 lets any authenticated user with write access to their own board relocate cards, lists, or swimlanes into a private board they do not belong to. The DDP update allow rules only authorize against the document's stored (source) boardId and never validate the attacker-supplied destination boardId in the update modifier, so /cards/update, /lists/update, and /swimlanes/update can be abused to inject content across a trust boundary. No public exploit identified at time of analysis, but the fixing commit and advisory publicly document the exact bypass, lowering the barrier to reproduction.

Technical ContextAI

Wekan is built on Meteor, which exposes collections to clients over DDP and gates writes through Meteor's allow/deny callback model. The affected code is the server-side allow rules in server/permissions/cards.js, lists.js, and swimlanes.js, which call allowIsBoardMemberWithWriteAccess against the document's current boardId. The root cause is CWE-284 (Improper Access Control): the authorization check binds to the source board the caller already controls, while the MongoDB-style update modifier ($set.boardId) can carry a different destination boardId that is never re-validated. Because Meteor allow rules approve if any rule allows and the modifier is applied after the check, the caller's ownership of the source board is sufficient to satisfy the guard, allowing a cross-board move. The fix (commit d369a36) adds a denyCrossBoardMove deny rule that inspects modifier.$set.boardId and denies the write unless the caller has write access to the destination board via allowIsBoardMemberWithWriteAccess.

RemediationAI

Vendor-released patch: upgrade Wekan to version 9.37 or later (https://github.com/wekan/wekan/releases/tag/v9.37), which introduces the denyCrossBoardMove deny rule enforcing write access on the destination board for Cards, Lists, and Swimlanes updates; this is the primary and complete fix per advisory GHSA-gm7v-pc38-53jr. If an immediate upgrade is not possible, reduce exposure by limiting account provisioning to trusted users and disabling or restricting self-service registration so that arbitrary authenticated users cannot obtain write-capable boards, and monitor board membership and card/list/swimlane audit activity for unexpected cross-board relocations; note these are only partial compensating controls because any legitimate writer remains capable of the move until patched. Operators can also cherry-pick commit d369a3614a4737c29d48a6345a790edf2506ddae onto an earlier build if they cannot take the full 9.37 release.