CVE-2026-59154: Wekan Auth Bypass Vulnerability

CVE-2026-59154 Overview

CVE-2026-59154 is a cross-board authorization bypass in Wekan, an open source kanban board application built on Meteor. The flaw, tracked internally as GHSA-gv8h-5p3p-6hx7 ("ChecklistBleed"), affects the direct Meteor collection allow rules for Checklists and ChecklistItems. The rules authorize updates only against the current source doc.cardId and never inspect the destination cardId or boardId in the update modifier. An authenticated user with write access to any board and knowledge of a target private card ID can create checklist data on an accessible card and then move it into a private board where they are not a member. The issue is fixed in Wekan version 9.64.

Critical Impact
A low-privileged authenticated user can write checklist data into private boards they do not belong to, breaking tenant isolation between Wekan boards.

Affected Products

Wekan versions prior to 9.64
Wekan Checklists collection allow rules (server/permissions/checklists.js)
Wekan ChecklistItems collection allow rules (server/permissions/checklistItems.js)

Discovery Timeline

2026-07-10 - CVE-2026-59154 published to NVD
2026-07-10 - Last updated in NVD database

Technical Details for CVE-2026-59154

Vulnerability Analysis

Wekan uses Meteor's Distributed Data Protocol (DDP) with client-side collection allow/deny rules to authorize writes. For Checklists and ChecklistItems, the update allow rules verify that the caller has write access to the board that owns the current doc.cardId. The rules do not inspect the update modifier, so a caller can change cardId to a card belonging to a private board and Wekan will still accept the write. The result is a broken access control condition classified as [CWE-863] Incorrect Authorization.

Exploitation requires only an authenticated Wekan account with write access to a single board and the ID of a card in a target private board. Board IDs and card IDs are opaque but leak through invitations, exports, past memberships, and shared URLs. Because the write happens through DDP directly against the collection, no server method boundary intervenes to re-check board membership on the destination.

Root Cause

The root cause is authorization performed against the source document only. The allow rule reads doc.cardId, resolves the parent board, and checks membership. It never compares the incoming modifier's cardId against the resolved destination board's ACL. Moving a checklist item across boards is therefore treated as a same-scope update.

Attack Vector

The attack is remote and network-based over the standard Wekan DDP endpoint. An attacker authenticates, inserts a checklist or checklist item on a card they legitimately control, then issues a DDP update that rewrites cardId to a card inside a private board. The write succeeds and the checklist data appears on the private card.

javascript

// Patch: server/lib/utils.js (v9.64)
 import Boards from '/models/boards';
+import Cards from '/models/cards';
+import Checklists from '/models/checklists';
 
 export function allowIsBoardAdmin(userId, board) {
   return board && board.hasAdmin(userId);
// Source: https://github.com/wekan/wekan/commit/b1ca76007b9a295fd029dfefc1a2d1d6f1920835

javascript

// Patch: server/permissions/checklistItems.js (v9.64)
 import Cards from '/models/cards';
 import ChecklistItems from '/models/checklistItems';
-import { allowIsBoardMemberWithWriteAccessByCard } from '/server/lib/utils';
+import { allowIsBoardMemberWithWriteAccessByCard, denyCrossBoardMoveByChecklistItem } from '/server/lib/utils';
 
 ChecklistItems.allow({
   async insert(userId, doc) {
// Source: https://github.com/wekan/wekan/commit/b1ca76007b9a295fd029dfefc1a2d1d6f1920835

The fix introduces denyCrossBoardMoveByChecklistItem, a deny rule that inspects the update modifier and blocks any change of cardId that would move a checklist item to a card in a board the caller cannot write to.

Detection Methods for CVE-2026-59154

Indicators of Compromise

Checklist or checklist item documents in MongoDB whose cardId points to a card on a board where the last-modifying userId is not a member.
DDP update messages targeting the checklists or checklistItems collections that include cardId in the modifier $set clause.
Unexpected checklist entries appearing on private board cards without a corresponding entry in the board activity log.

Detection Strategies

Query the MongoDB checklists and checklistItems collections and join against cards and boards to flag any item whose owning card's board does not list the modifier as a member.
Enable Wekan DDP-level logging and alert on update operations against checklists or checklistItems where the modifier changes cardId.
Compare board activities entries against checklist mutations; writes that lack an accompanying activity record indicate direct collection access.

Monitoring Recommendations

Ship Wekan application logs and MongoDB oplog data to a centralized SIEM and retain them long enough to cover the pre-9.64 exposure window.
Baseline the rate of checklist item cardId changes per user; investigate accounts that suddenly move items across board boundaries.
Monitor authentication logs for low-privileged accounts that access multiple board IDs within short time windows.

How to Mitigate CVE-2026-59154

Immediate Actions Required

Upgrade Wekan to version 9.64 or later, which introduces denyCrossBoardMoveByChecklistItem and equivalent guards for checklists.
Audit checklists and checklistItems collections for entries whose owning card belongs to a board the last modifier cannot access, and remove or quarantine them.
Rotate any secrets, credentials, or sensitive text that may have been exposed through checklist items placed on private boards.

Patch Information

The fix is delivered in Wekan release v9.64 via commit b1ca760. See the GitHub Security Advisory GHSA-gv8h-5p3p-6hx7 for the full advisory. The patch adds destination-side authorization by inspecting the update modifier and denying cross-board moves for checklists and checklist items.

Workarounds

Restrict Wekan write access to trusted users until the 9.64 upgrade is applied.
Place Wekan behind a reverse proxy that rate-limits DDP update traffic and logs modifier payloads for review.
Segment sensitive projects into separate Wekan instances so that a compromised account on one instance cannot pivot into private boards on another.

bash

# Upgrade Wekan to the patched release
docker pull wekanteam/wekan:v9.64
docker stop wekan-app && docker rm wekan-app
docker run -d --name wekan-app \
  --env-file /etc/wekan/wekan.env \
  -p 8080:8080 \
  wekanteam/wekan:v9.64

# Verify the running version
docker exec wekan-app cat /build/programs/server/assets/app/version.json