CVE-2026-55234: Wekan Auth Bypass Vulnerability

CVE-2026-55234 Overview

Wekan is an open source kanban application built with Meteor. A broken access control flaw ([CWE-284]) in versions prior to 9.37 allows authenticated users to move cards, lists, or swimlanes into private boards where they hold no membership. The DDP update allow rules in server/permissions/cards.js, server/permissions/lists.js, and server/permissions/swimlanes.js authorize actions against the stored source boardId and never validate a new boardId supplied in the update modifier. Any user with write access to their own board can call /cards/update, /lists/update, or /swimlanes/update to relocate content into boards they should not access. Version 9.37 remediates the flaw.

Critical Impact
Any authenticated Wekan user can inject cards, lists, or swimlanes into private boards, violating tenant isolation and integrity of restricted project data.

Affected Products

Wekan open source kanban server, all releases prior to 9.37
Meteor DDP /cards/update, /lists/update, and /swimlanes/update methods
Self-hosted Wekan deployments exposing multi-tenant boards to authenticated users

Discovery Timeline

2026-07-15 - CVE-2026-55234 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-55234

Vulnerability Analysis

The flaw is a broken access control issue in Wekan's Meteor server-side permission layer. The allow rules for cards, lists, and swimlanes gate updates by checking the caller's write access on the current document's boardId. They do not inspect the $set.boardId field inside the update modifier. An attacker submits a DDP update request against a document they legitimately own and includes a boardId pointing to a private board they are not a member of. The server evaluates only the source board, approves the write, and the document is relocated. The result is an integrity violation against restricted boards and unauthorized insertion into a private workspace.

Root Cause

Wekan's Meteor allow/deny rules validated authorization against the persisted boardId on the source document. They never re-checked the destination boardId provided in the mutation payload. Meteor's collection security model requires explicit deny rules for cross-tenant field changes, which were absent for the boardId field on the three collections.

Attack Vector

Exploitation requires an authenticated Wekan account with write access to at least one board. The attacker opens a DDP client, targets a card, list, or swimlane they own, and issues an update setting boardId to the identifier of a private board. No user interaction from the victim is required. The attack is scoped as network-accessible against the Wekan server. Refer to the GitHub Security Advisory GHSA-gm7v-pc38-53jr for advisory details.

javascript

// Patch: server/lib/utils.js
// Adds a deny rule that rejects updates moving a document to a
// destination boardId on which the caller lacks write access.
export async function denyCrossBoardMove(userId, modifier) {
  const set = modifier && modifier.$set;
  if (!set) return false;
  const newBoardId = set.boardId;
  // Nothing being moved across boards.
  if (typeof newBoardId !== 'string' || !newBoardId) return false;
  // Caller must have write access to the destination board.
  return !allowIsBoardMemberWithWriteAccess(
    userId,
    await Boards.findOneAsync(newBoardId),
  );
}

Source: GitHub Commit d369a361

javascript

// Patch: server/permissions/cards.js
// Wires denyCrossBoardMove into the Cards deny() rules.
import Cards from '/models/cards';
import Boards from '/models/boards';
import {
  allowIsBoardMemberWithWriteAccess,
  denyCrossBoardMove,
} from '/server/lib/utils';

Source: GitHub Commit d369a361

Detection Methods for CVE-2026-55234

Indicators of Compromise

DDP /cards/update, /lists/update, or /swimlanes/update calls whose $set modifier contains a boardId that differs from the document's stored boardId.
Cards, lists, or swimlanes appearing on a private board with a createdBy or userId that does not match any member of that board.
MongoDB audit entries showing boardId field mutations on the cards, lists, or swimlanes collections initiated by non-member accounts.

Detection Strategies

Instrument the Meteor DDP endpoint to log update payloads and flag any request where modifier.$set.boardId is present.
Run periodic MongoDB integrity queries that join documents against their boardId and report members mismatches.
Correlate Wekan application logs with board membership changes to spot unexpected content injection.

Monitoring Recommendations

Forward Wekan server logs to a centralized logging or SIEM platform for retention and alerting.
Alert on spikes in cross-collection boardId modifications, which are uncommon in normal workflows.
Review private board activity feeds for unattributed entries added by non-members.

How to Mitigate CVE-2026-55234

Immediate Actions Required

Upgrade Wekan to version 9.37 or later, which introduces the denyCrossBoardMove rule across cards, lists, and swimlanes.
Audit private boards for foreign content by comparing document boardId values against board membership rosters.
Rotate session tokens for accounts suspected of abusing DDP update endpoints.

Patch Information

Wekan version 9.37 remediates the issue. The fix commit d369a361 adds the denyCrossBoardMove helper in server/lib/utils.js and registers it as a deny rule for the cards, lists, and swimlanes collections. See the GitHub Release v9.37 and the GitHub Commit d369a361 for full details.

Workarounds

Restrict Wekan write access to trusted user groups until the upgrade is applied.
Place Wekan behind an authenticated proxy that inspects DDP messages and blocks update payloads containing boardId in the $set modifier.
Take backups of private boards so unauthorized content injection can be reverted.

bash

# Upgrade Wekan to the patched release
git fetch --tags
git checkout v9.37
meteor npm install
meteor build ../build --architecture os.linux.x86_64
# Restart the Wekan service after redeploying the built bundle
systemctl restart wekan