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:

Authentication verification - No check to ensure the user is logged in before processing requests
Authorization validation - No verification that the requesting user has visibility permissions on the board containing the attachment
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

javascript

       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:

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

bash

# 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