CVE-2026-1963: WeKan Auth Bypass Vulnerability

CVE-2026-1963 Overview

A vulnerability was found in WeKan up to version 8.20. This security issue affects the file models/attachments.js within the Attachment Storage component. The vulnerability arises from improper access controls, allowing authenticated attackers to potentially access or manipulate attachments without proper authorization checks. The attack may be launched remotely over the network by authenticated users.

Critical Impact

Remote authenticated attackers can exploit improper access controls in WeKan's attachment storage functionality to access attachments belonging to boards they do not have permission to view, or manipulate storage destination parameters without proper validation.

Affected Products

• WeKan versions up to and including 8.20
• WeKan Attachment Storage component (models/attachments.js)

Discovery Timeline

• February 5, 2026 - CVE-2026-1963 published to NVD
• February 5, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1963

Vulnerability Analysis

The vulnerability exists in WeKan's attachment handling mechanism within the models/attachments.js file. The affected function allows users to move attachments between storage destinations without properly verifying whether the user has legitimate access to the board associated with the attachment. This broken access control vulnerability (CWE-266: Incorrect Privilege Assignment) enables authenticated users to perform operations on attachments from boards they should not have access to.

The root issue stems from missing authentication and authorization checks before performing sensitive operations on attachment objects. Without these checks, an authenticated user could reference any attachment by its ID and perform storage migration operations regardless of their relationship to the associated board.

Root Cause

The vulnerability is caused by insufficient access control validation in the attachment storage management functionality. The original code failed to implement three critical security checks:

1. Authentication verification - No check to ensure the user is logged in before processing requests
2. Authorization validation - No verification that the requesting user has visibility permissions on the board containing the attachment
3. Input validation - No allowlist validation for storage destination parameters

Attack Vector

An authenticated attacker can exploit this vulnerability remotely by crafting requests that reference attachment IDs from boards they do not have permission to access. The attacker could potentially:

• Access metadata about attachments on private boards
• Trigger storage migration operations on unauthorized attachments
• Specify arbitrary storage destination values that may not be legitimate

       check(fileObjId, String);
       check(storageDestination, String);
 
+      if (!this.userId) {
+        throw new Meteor.Error('not-authorized', 'You must be logged in.');
+      }
+
       const fileObj = ReactiveCache.getAttachment(fileObjId);
+      if (!fileObj) {
+        throw new Meteor.Error('attachment-not-found', 'Attachment not found');
+      }
+
+      const board = ReactiveCache.getBoard(fileObj.boardId);
+      if (!board || !board.isVisibleBy({ _id: this.userId })) {
+        throw new Meteor.Error('not-authorized', 'You do not have access to this board.');
+      }
+
+      // Allowlist storage destinations
+      const allowedDestinations = ['fs', 'gridfs', 's3'];
+      if (!allowedDestinations.includes(storageDestination)) {
+        throw new Meteor.Error('invalid-storage-destination', 'Invalid storage destination');
+      }
+
       moveToStorage(fileObj, storageDestination, fileStoreStrategyFactory);
     },
     renameAttachment(fileObjId, newName) {

Source: Wekan Commit Details

Detection Methods for CVE-2026-1963

Indicators of Compromise

• Unusual attachment access patterns from users who are not members of specific boards
• Requests to the attachment storage migration endpoint with attachment IDs that don't belong to the user's accessible boards
• Error logs showing failed board visibility checks after patching (indicating blocked exploitation attempts)

Detection Strategies

• Monitor API calls to attachment storage migration functions for anomalous patterns
• Implement logging of all attachment operations including the requesting user ID and associated board ID
• Review access logs for attempts to reference attachments by ID without corresponding board membership
• Alert on repeated failed authorization attempts to the attachment storage endpoints

Monitoring Recommendations

• Enable detailed logging for all attachment-related operations in WeKan
• Implement rate limiting on attachment storage operations to detect enumeration attempts
• Configure alerts for authentication and authorization errors originating from the models/attachments.js component
• Review audit logs regularly for patterns of cross-board attachment access attempts

How to Mitigate CVE-2026-1963

Immediate Actions Required

• Upgrade WeKan to version 8.21 or later immediately
• Review access logs for any suspicious attachment access patterns prior to the upgrade
• Audit which users have accessed attachments on sensitive boards
• Consider implementing additional network-level access controls while planning the upgrade

Patch Information

The security issue is fixed in WeKan version 8.21. The patch is identified by commit hash c413a7e860bc4d93fe2adcf82516228570bf382d. The fix implements proper authentication checks, board visibility validation, and storage destination allowlisting.

For detailed patch information, see:

• Wekan Release v8.21
• Wekan Commit Details

Workarounds

• If immediate upgrade is not possible, consider restricting network access to the WeKan instance to trusted users only
• Implement a web application firewall (WAF) rule to monitor and limit requests to attachment-related endpoints
• Temporarily disable attachment storage migration functionality if not business-critical
• Review and restrict user account access to minimize the pool of potential authenticated attackers

# Configuration example
# Upgrade WeKan to patched version
docker pull wekanteam/wekan:v8.21
docker-compose down
docker-compose up -d

# Verify the version after upgrade
docker exec wekan-app cat /etc/wekan/version