CVE-2026-25561: Wekan Auth Bypass Vulnerability

CVE-2026-25561 Overview

WeKan versions prior to 8.19 contain an authorization weakness (CWE-863) in the attachment upload API. The API does not fully validate that provided identifiers (such as boardId, cardId, swimlaneId, and listId) are consistent and refer to a coherent card/board relationship, enabling attempts to upload attachments with mismatched object relationships. This vulnerability allows authenticated users to potentially bypass access controls by manipulating object identifiers in API requests.

Critical Impact
Authenticated attackers can exploit the object relationship validation bypass to upload attachments to cards they should not have access to, potentially compromising data integrity across boards in a WeKan instance.

Affected Products

WeKan versions prior to 8.19
wekan_project wekan (cpe:2.3:a:wekan_project:wekan:*:*:*:*:*:*:*:*)

Discovery Timeline

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

Technical Details for CVE-2026-25561

Vulnerability Analysis

This authorization bypass vulnerability exists in WeKan's attachment upload API endpoint located in server/routes/attachmentApi.js. The vulnerability stems from insufficient validation of the relationships between object identifiers provided in API requests. When a user uploads an attachment, they must provide multiple identifiers including boardId, cardId, swimlaneId, and listId. Prior to the fix, the API accepted these parameters without verifying that they formed a coherent and authorized relationship.

An authenticated attacker could exploit this weakness by providing valid identifiers that don't actually belong together—for example, using a cardId from one board while specifying a boardId for a different board where they have membership. This could allow unauthorized modification of cards across different boards within the same WeKan instance.

Root Cause

The root cause is improper authorization (CWE-863) in the attachment upload API. The original implementation verified that individual objects existed and that the user had board membership, but failed to verify that the provided cardId actually belonged to the specified boardId, or that the swimlaneId and listId matched the card's actual swimlane and list assignments. This gap allowed mismatched object relationships to be exploited.

Attack Vector

This is a network-based attack requiring low privileges (authentication). An attacker with valid credentials to a WeKan instance can craft malicious API requests with mismatched object identifiers. The attack requires:

Valid authentication to the WeKan instance
Knowledge of valid object identifiers (boardId, cardId, swimlaneId, listId) from different boards
Membership to at least one board in the system

The attacker sends an attachment upload request with identifiers that reference objects from different boards, bypassing the intended scope restrictions.

javascript

            return sendErrorResponse(res, 404, 'Board not found');
          }

+          // Verify that the card belongs to the specified board
+          if (card.boardId !== boardId) {
+            return sendErrorResponse(res, 400, 'Card does not belong to the specified board');
+          }
+
+          // Verify that the swimlaneId and listId match the card's actual swimlane and list
+          if (card.swimlaneId !== swimlaneId) {
+            return sendErrorResponse(res, 400, 'Swimlane ID does not match the card\'s swimlane');
+          }
+
+          if (card.listId !== listId) {
+            return sendErrorResponse(res, 400, 'List ID does not match the card\'s list');
+          }
+
          // Check permissions
          if (!board.isBoardMember(userId)) {
            return sendErrorResponse(res, 403, 'You do not have permission to modify this card');

Source: GitHub Wekan Security Commit

The security patch adds three critical validation checks: verifying the card belongs to the specified board, confirming the swimlane ID matches the card's actual swimlane, and validating the list ID matches the card's list assignment.

Detection Methods for CVE-2026-25561

Indicators of Compromise

Unexpected attachment uploads appearing on cards where users should not have access
API request logs showing attachment upload requests with mismatched boardId and cardId combinations
Audit logs indicating users uploading to cards in boards they are not members of
Unusual patterns of API requests to /api/boards/{boardId}/swimlanes/{swimlaneId}/lists/{listId}/cards/{cardId}/attachments with inconsistent identifiers

Detection Strategies

Implement API logging to capture all parameters in attachment upload requests and correlate boardId/cardId relationships
Monitor for HTTP 400 responses with messages indicating object relationship mismatches (post-patch)
Review access logs for users making attachment upload attempts across multiple boards in rapid succession
Configure alerting for any attachment modifications on boards where the authenticated user lacks explicit membership

Monitoring Recommendations

Enable detailed API request logging in WeKan to capture all object identifiers in upload requests
Implement SIEM rules to detect patterns of attachment upload attempts with inconsistent object relationships
Set up integrity monitoring on the attachments storage directory to detect unauthorized file uploads
Regularly audit board membership and attachment ownership to identify anomalies

How to Mitigate CVE-2026-25561

Immediate Actions Required

Upgrade WeKan to version 8.19 or later immediately
Review existing attachments to verify they are properly associated with their intended cards and boards
Audit user activity logs for any suspicious attachment upload patterns prior to patching
Consider temporarily restricting API access or attachment uploads until the patch can be applied

Patch Information

The vulnerability has been addressed in WeKan version 8.19. The fix, implemented in commit 1d16955b6d4f0a0282e89c2c1b0415c7597019b8, adds proper validation to ensure that all object identifiers in attachment upload requests form a coherent relationship before processing the upload. For detailed patch information, refer to the GitHub Wekan Commit and the Vulncheck Security Advisory.

Workarounds

Implement a reverse proxy or WAF rule to validate that attachment upload requests contain consistent object relationships
Restrict API access to trusted networks or require additional authentication for attachment uploads
Temporarily disable the attachment upload feature if not critical to operations until patching is possible
Use application-level access controls to limit which users can upload attachments

bash

# Example: Verify WeKan version after upgrade
docker exec wekan cat /home/wekan/.meteor/local/version || wekan --version

# Example: Check for the security patch in the codebase
grep -n "Card does not belong to the specified board" /path/to/wekan/server/routes/attachmentApi.js