CVE-2026-2205: Wekan Information Disclosure Vulnerability

CVE-2026-2205 Overview

A significant information disclosure vulnerability has been identified in WeKan, the open-source kanban board application, affecting versions up to 8.20. This vulnerability exists within the Meteor Publication Handler component, specifically in the server/publications/cards.js file. The flaw allows authenticated attackers to access card data from boards they should not have visibility to, bypassing the intended access control mechanisms.

Critical Impact
Authenticated users can access sensitive card information from boards they are not authorized to view, potentially exposing confidential project data, tasks, and organizational information across the WeKan installation.

Affected Products

WeKan versions up to and including 8.20
WeKan installations using Meteor Publication Handler for card subscriptions
Self-hosted and cloud-deployed WeKan instances running vulnerable versions

Discovery Timeline

2026-02-08 - CVE-2026-2205 published to NVD
2026-02-11 - Last updated in NVD database

Technical Details for CVE-2026-2205

Vulnerability Analysis

This information disclosure vulnerability (CWE-200) stems from insufficient authorization checks in the WeKan card publication mechanism. The vulnerable code in server/publications/cards.js failed to properly validate whether a user has permission to view a board before publishing card data to the client. This creates a scenario where the Meteor publication could leak card information to users who should only have access to boards they are explicitly members of or where board visibility rules should restrict access.

The vulnerability is exploitable remotely over the network and requires low-privileged authentication to execute. The impact is limited to confidentiality loss, with no direct effect on integrity or availability of the system.

Root Cause

The root cause of this vulnerability lies in the improper ordering and completeness of authorization checks within the card publication handler. The original code structure performed access control validation only after certain conditions were met, and critically, it did not validate board visibility before processing card subscriptions. The authorization logic checked for assigned-only permissions but failed to first verify that the user had any legitimate access to the board containing the card.

Attack Vector

An authenticated attacker can exploit this vulnerability by subscribing to card publications for cards they should not have access to. By manipulating card IDs in subscription requests, an attacker with a valid WeKan account can potentially enumerate and access cards from private boards, boards where they are not members, or boards with visibility restrictions that should prevent their access.

The attack is performed remotely over the network, requires only a low-privileged account (basic authentication), and does not require any user interaction.

javascript

   const userId = Meteor.userId();
   const card = ReactiveCache.getCard({ _id: cardId });
   
+  if (!card || !card.boardId) {
+    return [];
+  }
+  
+  const board = ReactiveCache.getBoard({ _id: card.boardId });
+  if (!board || !board.isVisibleBy(userId)) {
+    return [];
+  }
+  
   // If user has assigned-only permissions, check if they're assigned to this card
-  if (userId && card && card.boardId) {
-    const board = ReactiveCache.getBoard({ _id: card.boardId });
-    if (board && board.members) {
-      const member = _.findWhere(board.members, { userId: userId, isActive: true });
-      if (member && (member.isNormalAssignedOnly || member.isCommentAssignedOnly || member.isReadAssignedOnly)) {
-        // User with assigned-only permissions can only view cards assigned to them
-        if (!card.assignees || !card.assignees.includes(userId)) {
-          return []; // Don't publish if user is not assigned
-        }
+  if (userId && board.members) {
+    const member = _.findWhere(board.members, { userId: userId, isActive: true });
+    if (member && (member.isNormalAssignedOnly || member.isCommentAssignedOnly || member.isReadAssignedOnly)) {
+      // User with assigned-only permissions can only view cards assigned to them
+      if (!card.assignees || !card.assignees.includes(userId)) {
+        return []; // Don't publish if user is not assigned
       }
     }

Source: GitHub Commit Details

Detection Methods for CVE-2026-2205

Indicators of Compromise

Unusual patterns of card subscription requests from single user accounts attempting to access multiple board IDs
Access log entries showing users retrieving card data from boards they are not members of
Meteor DDP (Distributed Data Protocol) subscription logs showing unauthorized card publication requests
Anomalous spikes in card data retrieval that deviate from normal user behavior patterns

Detection Strategies

Implement logging on Meteor publication handlers to track card subscription requests and correlate with user board memberships
Configure application-level monitoring to alert on card access attempts where the requesting user is not a board member
Deploy network monitoring to identify unusual DDP message patterns targeting card subscriptions
Review WeKan access logs for patterns of sequential card ID enumeration attempts

Monitoring Recommendations

Enable verbose logging for server/publications/cards.js to capture all card subscription events with user context
Set up alerting for failed authorization checks in card publication handlers
Monitor for users accessing cards at a rate inconsistent with normal usage patterns
Implement real-time dashboard monitoring for Meteor subscription activity across boards

How to Mitigate CVE-2026-2205

Immediate Actions Required

Upgrade WeKan to version 8.21 or later immediately to apply the security patch
Review access logs to identify any potential exploitation attempts prior to patching
Audit board membership and permissions to ensure access controls are configured correctly
Notify users if sensitive data may have been exposed through this vulnerability

Patch Information

The vulnerability has been addressed in WeKan version 8.21. The fix implements proper board visibility validation before processing card subscriptions, ensuring that the board.isVisibleBy(userId) check is performed early in the authorization flow. The security patch is available in commit 0f5a9c38778ca550cbab6c5093470e1e90cb837f.

Administrators should upgrade to version 8.21 or apply the patch from the official commit.

Workarounds

If immediate patching is not possible, consider temporarily restricting network access to the WeKan instance to trusted users only
Implement additional reverse proxy authentication layers to limit who can reach the WeKan application
Disable public registration and audit all existing user accounts for unauthorized access
Consider temporarily setting all boards to private and manually verifying board membership lists

bash

# Configuration example
# Update WeKan to patched version 8.21
cd /path/to/wekan
git fetch origin
git checkout v8.21

# For Docker deployments
docker pull wekan/wekan:v8.21
docker-compose down && docker-compose up -d

# Verify the patch is applied by checking the commit
git log --oneline -1 server/publications/cards.js
# Should show commit containing the security fix